Sunday Jul 30, 2006

The Eighties Need Some Fixing

If you had control, what would have been your perfect Eighties TV show? I'd go for KITT and Patrica McPherson from Knight Rider, teamed up with MacGyver instead of D.H. Bonnie is a hacker and gets some real dialogue, and KITT is the ambivalent cyberpunkish AI in the background. The setting is Earth and sometimes the secret base, Battlestar Galactica, hidden cleverly on the backside of the moon opposite a nuclear dump, whose explosion (caused by MacGyver with a piece of bubblegum) blasts the moon on a journey through the galaxy after a breathtaking cliffhanger at the end of the first season. The bad guys are played by Nimoy and Landau, while KITT may or may not be pulled over to the dark side by Matt Frewer. At the end of the second season (that's the one in space), McPherson disapears under mysterious circumstances, and is replaced for one season by Jessica Steen, who has been heroically saved by MacGyver from an annoying life among alien robots. The title theme is of course from Doctor Who. ... See! It's so easy to come up with good ideas. Why didn't they record a show like that 20 years ago, hm?

And look! I found another thing from the eighties(?) that needs fixing, my old harmonica. Sorry harmonica, this blog category is labled Hacks, and this means I have to take something apart, and this time it's you. I found it again in a box and (despite never having learned how to play) I tried to elicit some notes. Turns out that some notes didn't sound anymore. At least not more than a faint eep. Bummer.

But since we live in the age where information's at your fingertips, I go check out a webpage by a harmonica enthusiast and am told that the problem's obviously due to the reed gaps being to wide. Of course! It's that obvious! ... Alright. ... What are reed gaps? Only one way to find out. >:-) \*Takes out Swiss army knife\*

Look, reeds! And gaps! Everywhere! So what I learned this weekend was: The perfect reed gap must be as wide as its reed is thick. It may be a fraction wider if you play loud, and a trifle less, if you play softly. Also I learned that the reeds on the outside produce most of the sound when you inhale, and the ones on the inside when you exhale. Oh, and if the base is on the right side, and the high notes on the left, the cover is the wrong way round. >:-) \*Takes out Swiss army knife again\*

Thursday Jul 13, 2006

Don't Write on the Backside of Paper (2)

Last April or so, I blabbered about 3D desktops. Today I find a prototype: BumpTop. Thanks, Canadians, that was quick. "But oh, you, like, forgot the file names! :p"

Of course this prototype is still far from being useful, but I think it doesn't hurt to experiment with the idea. One needs to start somewhere. If it at least results in a one nice photo browser or something I would already consider it success. Maybe over time, the idea refines and develops, who knows. I mean, come on, somebody must be able to come up with something. Whatever it will turn out to be, it will be named Sun Java Cubeform Third Dimension Plug-Around Module Pack for NetBeans ID3. Or maybe — 3Doogle.

Oh. Wait. I am suddenly worried. About support phone-calls. And written documentation. Hm... The more intuitive and less textual interfaces get, the more difficult it gets to describe an interaction in words... 8-| Neglecting the fact that you shouldn't, it's easy to explain to a beginner on the phone how to type in "R M blank minus R F blank star, now press return-key". And yes, sure, the most unspeakable mouse gestures will eventually be given handy names, in much the same way as complex facial gestures were given concise names like LOL, Argh, or Duh. But still — do you want to be the guy explaining correct mouse gestures to the panicky businessman who just accidentally swished his live's work into the dark little hole in the corner of the screen where the screensaver lives? Well?? See! \*shudder\*

Wednesday Jun 28, 2006

Embedded HTML Editor for Bloggers and Wikians

Now that's a cool firefox plugin if I ever saw one, Xinha! -- A WYSIWYG HTML editor embedded in your browser. Very useful for bloggers and wiki writers who use HTML. (Some wikis do.) You install Xinha! from addons.mozilla.org, and after it's loaded (restart the browser) it's accessible in the context menu of each text input field of your browser. Like this text input field I use right now to type this blog entry. So I right-click, and I can choose to open the Xinha Editor in either its own window, or in a frame at the bottom of the webpage I am working on.

If the text input field already contains some text, Xinha copies it over into the Xinha buffer, where you can edit it in a basic HTML composer GUI. The GUI even has skins. Tsk. ;-) After you made your edits in the textfield, scroll down to the Apply button (I didn't find it at first) and this will copy the Xinha buffer as html into the text input field.

Note that each Xinha seems to be tied to the textfield you open it for! This is important. So when you tab to another page, and keep using the same Xinha window, your changes will be pasted into the original text field, and not the one in the tab you happen to be looking at right now. Also, if you reload the page (e.g. for saving changes while blogging every 5 min or so), the Xinha window does stay open, but seems to lose the connection to the new instance of the textfield. Keep that in mind when using it.

Pretty impressive idea! It would be perfect if it wasn't for one display bug: In my Linux Firefox, the Xinha frame buffer blinks and moves around constantly while redrawing. Twice per second. Pretty annoying, but I hope that will be fixed in future versions. Try it! :)

Tuesday May 16, 2006

Does Your GUI Clack or Rattle?

OK, here is my brainstorming about what Karsten Lentsch said at JavaOne about Swing GUI Design Dos and Don'ts. He had a weird kind of dry humor that made the audience laugh while he kept a straight face. Oh and I will also sum up what he said about the NetBeans GUI builder Matisse in this context.

  1. The GUI mustn't distract the viewer's attention. Visual representations are like poetry: Be aware that people intuitively try to assign meaning to every constellation of color, position, shade, blinking, movement, weight, size, alignment, they encounter: So don't send a message you don't want to send! (E.g. the fact that components are not aligned can be interpreted as that they don't belong together.)

  2. Fancy is not cool: Avoid sprinkling the GUI with blotches of saturated colors, noisy backgrounds, large or bold fonts, or fonts of different families (unless you want the reader to focus on only this odd-one-out, which you ususaly don't). Everything that strays from the standard is in the spotlight. If suddenly everything is in the spotlight, the users is blinded and stumbles around without guidance.
    You usually only want the workflow to be in the spotlight -- This is e.g. why headlines are few, short, bold, large, and in a different font.

  3. Be consistent with icons, theme, colors - also with respect to the OS. Don't swap/move positions of items if you have multiple dialogues or menues (e.g. don't swap "save" and "delete".) "Muscle memory" makes people associate positions with actions, so don't waste their time by forcing them to regather this information for every screen. Think of walking up a staircase where every step has a different height, you'd hate that!

  4. If the component/label doesn't add essential information, skip it! Can the user tell in one glance what the tool does? Make a Squint test to find out what stands out first. Be clear (remove noise), concise (nobody is ever going to read that). A GUI is not a 3-minute pop song, it's a tool in your hand that you use to accomplish something: If a button doesn't do what expected, you'll want your money back.

  5. One of Lentsch's metaphors was, if you brush over the interface with your fingernails, it should clack, not rattle. So no unnesessary lines: No double lines/borders between components, no nested titleborders, no gratuitous pseudo-3D effects. Use white space to group components instead of separator lines. Subtle gradient backgrounds can help to counterbalance other components' overhead weight.

  6. Symmetry, Grid & Alignment: Align components that have something in common! The user will thank you for this additional information. Align textfields to the fontbaselines. All fields should have the same size and spacing -- unless you want to convey the message that textfields of certain lengths are meant for contents of certain lengths (phone numbers, ZIP codes). In the latter case, constrain yourself to max. 3 sizes (small, medium, large textfields.)
    If the component's content is known and fixed in size, use static component sizes; dock or split windows only if necessary. Use a few aesthetic aspect ratios when spreading the components.

In Matisse he saw a great step in the right direction (e.g. it nicely aligns to fontbaselines), but he pointed out some weak spots: Matisse lacks guided alignment of components in multiple panels/windows/components, and it allows aligned components to have different heights. (When I'm back I need to try whether InterfaceBuilder can do that?) So don't count on a tool to do all the thinking for you.

So why are all these aesthetics relevant? Isn't the tool's function way more important? Unfortunately, humans tend to interpret good looks as health, and balanced GUI design as clear bugfree programming... Just flip the coin: If the GUI looks brittle, confused, clumsy, careless, users will have prejudice against it: "What is this klutz tool going to do with my precious data?" Oops, just lost a customer.
I'm well aware there are "ugly" but popular applications, but these often merely lack professional graphics, while their layout is intuitively clear and easy to use (and that counts).

Monday May 15, 2006

Amok running robots at JavaOne

How cute, a silver iMac on wheels in the JavaOne pavilion! Oh wait -- that's Tommy? Let's see what this egg on wheels is up to: Luckily, there were still empty seats in the "A robotic dune buggy named Tommy" session. (The alternatives would have been a session on AJAX, and one on Swing animations, still, Tommy's session was a good choice. There'll be other AJAX stuff). This technical session covered the DARPA grand challenge of Oct 2005. The challenge is a forum for building and testing real robotic vehicles, the winner receives an appropriate financial reward. The experience gathered will later be used for military, personal or professional purposes, for example, military surveilance, the handling of dangerous objects, or work in live-threatening environments. They say. Or maybe they just want to play with robots.

The challenge's goal is briefly to create an autonomous vehicle that can (for starters) travel through a desert and reach a target without any human intervention. Remember the Mars buggies of late? A planet's surface is not a German freeway. Every step has to be planned, discussed with ground control (radio signals from Mars can take something like 15 minutes), and then the step has to be taken slowly and carefully, or it'll be their last. But the DARPA challenge is different, as the vehicle has to complete the task at "mission-relevant" speeds, too. When the first grand challenge was held, even the best robots got stuck after 10km. But in the following years, the winners already managed to cover the whole alloted distance. On the other hand, each year a random number of great brave robots crashes, burns, or simply bails out during the first few meters -- it's by far not a trivial task, as we will see later.

Tommy is a cool retro-looking silver egg-shaped vehicle. He seems to be propelled by gas like a car and is pretty DIY, thanks to the team-members' enthusiasm and dedication. In the design phase (going from cardboard-box-sized to increasingly bigger robots) redundancy was already an essential part of the plan. You never know when one or the other signal doesn't come through. And, to be honest, you could count on the DARPA choosing a terrain that was not fully covered by the conventional global positioning system (GPS), just to make the game more interesting. So the Perrone team made sure to equip Tommy with a triple redundant navigational system: Two high-resolution GPSs (one beacon- and one satellite-guided), plus a lower-resolution standard GPS. Additionally, Tommy got two kinds of radars and lots of outside sensors, as well as internal state sensors. All that was orchestrated by one microprocessor that could make decisions and send them to the actuators (the motors and wheels that make the vehicle speed up, slow down, break, or turn).

The software used was a general purpose Java-based robotics platform, "Perrone MAX", if I remember correctly. Basically, you have threads running that are triggered by certain cofigurations of sensor input and internal state. Tommy's got a kind of artificial intelligence, pre-defined rules that allow him to make quick and good choices. The AI does not involve any machine learning however, the rules are hand-coded in Java. Some jinxers may claim, neither the Java Standard nor the Micro Edition would really scale to this kind of task -- so just to prove them wrong, Tommy's software uses both: Java ME and Realtime Java SE. Realtime means, that processes have a higher priority even over the garbage collection processes. Garbage collection slows down importantant realtime actions by milliseconds, a delay that you could cope with during a game of Minesweeper, but not when your autonomous robot is trying to defuse an actual bomb. Thanks to Java (and NetBeans IDE, woot!) :-) Tommy fulfills his demanding tasks happily with one microprocessor, and they detected no performance bottleneck what-so-ever.

After his "training", Tommy was able to complete several tasks, among other things:

  • He could find his way to waypoints in the desert with aid of GPS;
  • Sensors told him to slow down in time to not roll over or tilt.
  • He could drive through a dark tunnel without GPS -- at least for 30 secs.
  • He could resolve obstacles in a 500-feet range (170 meters) and kept track of them in his memory. At the same time he made sure not to pollute his obstacle map with, say, blades of gras, so the obstacle avoidance methods calculated the urgency by confidence level. E.g. an obstacle that only was detected once may be a sensor error and should not be avoided.

When the big day (week?) arrived, the first runs were pretty promising: Silver Tommy (named after Thomas Jefferson) was the big star -- until he ran amok. Inexplicably, he totalled himself during 4th test run. Just ran straight into a wall on the test site. (Allegedly, he was trying to go to the beach). The "port-mortem" revealed: Yes triple failures are possible. :-( After some "Refactoring" and a 36h rebuild though,Tommy was up and running again. Luckily, the sensors had not broken and only needed recalibration. Would Tommy be given a second chance? No - unfortunately, he was no longer allowed to take part in the race. All this after 10-men-months of work, 60k$ spent on material and 30k$ on travel. :-(

But Tommy will not give up! Perrone is already prepping him for the next grand challenge -- Navigation in a city! Tommy has to learn to get around moving obstacles and to behave properly in traffic circles. And there is one more city-style task to fulfill that would make us all very proud of Tommy: back into a parking space. :-P

Tuesday Mar 21, 2006

Never Use rm After Seven

It should be internationally outlawed and illegal to delete files after more than eight hours at work. Especially, the rm command should check the local time and say, Sorry dude, you're no longer certifiably sane, and no, the fact that you are still able to type :%s/smf/and/g into vi doesn't mean your wide awake, it means you're too tired to spell "and" correctly. (In my own defense I have to add that this is only a made-up example.)

But the following really happened -- I just deleted the directory I was working in. \*BONK\* I mean, there was a lot of stuff taking up space on my harddrive, and I just thought, hey, it's cvs, I can delete it locally, right? Just maybe I should have skipped deleting the dir I had checked out and just had started making changes in. Changes I had not yet commited back to cvs yet. So what to do?

Not to worry! Luckily, it was only two HTML files, and when I work with HTML, I usually keep a browser preview of the local file I'm working on. The files I deleted were still open in the browser. So just save them and I'm fine, right? Problem is -- the browser doesn't save from its cache. It tries to access the real thing before saving. Which didn't exist anymore.

Let's try something else. I can select the text in the browser and copy&paste it into a text document, but then I'd lose all formatting. Well -- better than nothing anyway. Luckily being tired doesn't only make you think in strange ways that make rm -rf look like a space-efficient backup command. Sometimes being tired is good for lateral thinking: Is the formatting really not preserved in the clipboard? What would happen if I paste it into an HTML editor? Only, since I hardly ever use an HTML editor, I couldn't think of any. Hmmm. My very first webpage I think I made in Netscape Composer. Netscape doesn't exist any more. Probably got accidentally deleted after seven. So let's try 'mozilla'. Lo and behold, my Fedora has mozilla installed. And even loer and beholder -- it still works exactly the same as netscape! Just choose Composer from the Windows menu and you have at least some HTML editor. I paste the clipboard and ta-daa -- my file is back in all its HTML glory. Composer didn't even get time to insert its annoying 'compliance' tags. :-p I only lost the meta tags, but they are easily restored.

And the moral of the story: Not only backups, but also caches, clipboards and old Composers can be your friend.

Monday Jan 23, 2006

How to Make Thunderbird Display Mailinglist Digests

I finally left Evolution Mail behind -- it crashed several times a day as response to simple actions like copy&paste or drag&drop. It also choked on long emails and died several times just formating a mailinglist digest message. I had to kill it the hard way, and as soon as it came up, quickly click another mail folder, otherwise it would fall into this "but I'm not finished formatting yet" trap over and over again.

Instead of Evolution, which I was using mainly for its calendar function, I switched to Thunderbird + kOrganizer for the calendar. Thunderbird behaves and is nice and searches through messages fast, no complaints up to now (I have been using it for one or two weeks now). kOrganizer's alarm (as opposed to kOrganizer itself) is confused about the time and date however, and its preferences pane shows up empty, so I can't set it... I assume I could fix the alarm by logging out or rebooting, but I do that so rarely in Linux that it just hasn't happened yet.

I'm signed up to the digest version of nbusers support list, a really active list which was growing annoyingly hard to read in Evolution. Then in Thunderbird, I was in for a surprise -- It didn't display the digest's content at all! What kind of mail client is that, if it only lists three millions attachments but skips the content? None of the settings (like "view inline") would change this behaviour.

By chance I found a solution today in a forum thread where somebody asked why his "Attachments fill up the Window". So that's what is happening! It doesn't skip the content, just the pane that lists all the attachments (which can be quite a number in a digest) is not set to scroll, but takes up the whole window instead, so the mail content is below the threshold without any scrollbar... I consider that a minor bug in the choice of default settings, but anyway, I found the solution:

Edit or create the file ~/.thundebird/yourprofile/chrome/userChrome.css and add the following lines (65px is just an example that worked for me)

#attachmentView {
max-height: 65px !important;
overflow: scroll !important; }

That's it -- the attachment list shrinks to a more handy size, and the content pane is fully visible again. And now I have about 10 digests left to read... Argh!

Monday Sep 19, 2005

Does Text-Only Nostalgia Pay Off?

Can anybody please come up with an explanation for this phenomenom? (other that coincidence, paranoia or selective perception, please. ;-) It is quite reproducible) It's freaking me out.

In Linux, I keep a sticky xload open to monitor my CPU load. Sometimes, an over-eager application takes up all the memory, causing everything to slow down to a halt, until the app crashes and Linux returns to normal behaviour. (Positive Thinking: At least all other apps and the OS remain stable...) Well, everytime this happens, I immediately see the value rising steeply in xload. I sigh and watch the GUI growing less and less responsive while the load habitually goes up to 20... 30 over a minute or two, until Linux finally realises it's hopeless and kills the amok running app.

Sometimes in this situation I switch over to the text terminal with ctrl-alt-F1. Even with a high load, it feels much more responsive since it does not have to bother about drawing a GUI. I run top to watch what's happening -- and never do I see the load rising.

What's going on here? When I stay in the GUI, Linux is pissed and the load rises like phoenix with his rump on fire -- when I switch to the text terminal, Linux suuuddenly feels flattered by nostalgia and condescents to kill the swapping app immediately, causing the load to drop? Is this a feature?

Tuesday Sep 13, 2005

Bah, they never recruit ME...

Oops. The Open Source guru Eric S. Raymond claims to have received a stray standard recruitment email from (ta-daa!) Microsoft?!

As you can imagine, those are the things in life that really get a hacker's "RAM swapping", so he bleats back the second most spiteful reply since Monkey Island... o_O

Wednesday Sep 07, 2005

File shortcuts in Linux

In Windows and MacOS, you can create handy desktop shortcuts to access files and directories whose paths you never are able to memorize. In MacOS, such a shortcut is called alias. In Linux, shortcuts are called symbolic links (symlinks); they are created using the terminal command ln. Some use cases:


Simplest case: You want to create a symlink to /long/path/to/dir/myfile in the current directory and give the shortcut the same name as the original (myfile), then you type
ln -s /long/path/to/dir/myfile
To create a shortcut to /long/path/to/dir/myfile in the current directory, but set the shortcut's name to myShortcut
ln -s /long/path/to/dir/myfile myShortcut
All together now: To create a shortcut to /long/path/to/dir/myfile in the directory /path, and set the shortcut's name to myShortcut
ln -s /long/path/to/dir/myfile /path/myShortcut

For directories, it works the same way.
Useful tips for using the Terminal command ln:

  • What's the difference between a symlink and a hard link? When specifying the ln -s option, you get a symbolic link, without it, you get a hard link to the file or directory. If you want a Windows-style shortcut it's a symlink, so you must use the -s option. Symlinks are clearly marked and can be deleted without the original being touched. But beware, if someone deletes The One Original(tm), all of the symlinks will irrecoverably break!
    Hard links on the other hand, never break, as long as one of the instances still exists — no matter which. In other words, hard links allow you to have one (original) file in many places under different names. Note, that you will not be able to tell a hard link from its original! They are the same. You edit one, you edit all. You need to keep track of hard links yourself.
    You see, the reason why beginners use symlinks is, symlinks are clearly marked and less confusing. ;-)
  • How to remove a hard link? Use the unlink command on the one of the hard links that you do no want to keep. Be careful when unlinking the last instance of the file, or when unlinking a normal file: Unlinking will quietly remove these files without any warning! (Actually, they are still on you harddrive, but you won't be able to find them anymore...)
  • How to remove a symlink? Symbolic links can be savely deleted with the rm command. If you should get the error message "rm cannot remove directory", do not out of a habit use rm -rf mySymlink/\* on a symlink to a directory, because that will delete the original's content! Instead make sure not to end the symbolic link's name in a slash when removing it. (You may get a slash in the end if you let the shell complete a link to a directory by pressing the tab key).
  • Many people have trouble remembering the order of the arguments to ln. :-) It's actually the same order that cp and mv use: First the source, that's the existing file or directory where you want the link to point to, then the target, that's the shortcut's name. If you mix up source and target, you create a useless link pointing nowhere inside the target directory (or you get an error message). Confused? Just keep one thing in mind: The first argument must be the source — because specifying the file or directory to link to is obviously mandatory. The target, however, is second, because it's optional — if you don't supply it, ln can just use the original file's name and place the shortcut in the current working directory by default.
  • How to tell what's a file and what's a link? The Linux shell usually marks symlinks, either by a color or by adding a character like @ to the file name. (You never type the @ when working with the symlink, though!) If you are not sure, you can get more information about your files by listing them with ls -l. This will clearly mark symlinks with a small letter L at the beginning of the line and a little arrow after the name plus the path where they point to.
    There is no way to tell a hard link from a 'normal' file! Like I said, they are the same thing, one file appears in two different places at the same time.

Here is an example of what symbolic and hard links look like in the wild. Note the L and the arrows identifying myfile and myShortcut as symlinks. Symlinks are usualy suspiciously small (compared to what you'd expect from a real file) and their change/creation dates are the dates of the symlink's change/creation, not the original's!
The files split_personality_one.txt and split_personality_too.txt don't look any different than just_some_normal_file.txt, but they are actually hard links! Psst, tell you a secret: All hard links of a flock have the same size and date... (that's the only hint you'll get from the shell about their identity.)
[jane:~]> ls -l
lrwxrwxrwx 1 jane users 65 Aug 15 15:19 myfile -> /long/path/to/dir/containing/the/original/myfile
lrwxrwxrwx 1 jane users 65 Aug 19 11:59 myShortcut -> /long/path/to/dir/containing/the/other/myfile
-rw-r--r-- 1 jane users 3471 Sep 1 11:22 just_some_normal_file.txt
-rw-r--r-- 2 jane users 763 Aug 24 17:14 split_personality_one.txt
-rw-r--r-- 2 jane users 763 Aug 24 17:14 split_personality_too.txt

Thursday Aug 18, 2005

Evolving Migraine from 'Evolution' Migration

(or “Cut out the stupid puns and fix my Linux pleeease!”)

Since working in a mounted home directory was slowing things down, I decided to move to a local home dir instead. Usually you can migrate apps in Linux by simply copying the old dot-files to the new location before starting the app there for the first time.

Not so the Evolution mail client. Only my mail is there (which has cowardly been camping up on the IMAP server and therefore doesn't count), — contacts, calenders and tasks didn't make it out alive. Annoyingly enough, I now can't even add new items to neither calendars nor tasks, and the import function gives some vage "failed access" error for reading in its own old dot-files (which I first had to copy to my home dir, because the file browser didn't care to list those useless dot-directories such as, say, ~/.evolution/).

Just great. So I take a look at the Evolution files. Half of them are in ~/.evolution — and for some reason there're a couple more lurking in ~/.gconf/apps/evolution. Whatever, copying .gconf/ over to the new account doesn't do the trick, either. For, now that I have started Evolution for the first time, it has already taken control: I quit Evolution, edit some config files, restart Evolution — and the files are restored with their old (useless) content. WTF? “Hurray for the new gPaddedCell demon, codename Sysiphus!”, or what? I for my part suspect this fishy gconfd process. Silly modern trinkets. What the hey, I just log out and use the text terminal, baby, gconfd doesn't do text. Sheesh, when I was your age, we had no gconfd. And no window manager other that fvwm2, and we were happy. We punched cards. With our teeth! In cuneiform, baby!

Anyway, where was I? Well, one ctrl-alt-F1 later I'm scanning through files checking boring read/write permissions and groups... nope, situation normal. I see my calendar data and my tasks there allright — Evolution just doesn't read them for some reason. Then I notice, in those %gconf.xml files, there's my old home path and my old hostname... Dang. If Evolutions takes these configs serious, it might just be protecting my personal data (calendar etc) from the "strange" user that I am now...

There is even some weird kind of ID number appearing in those %gconf.xml files: uid="1121950749.6099.12@oldhostname"? The first number changes rarely and looks similar to the timestamps those files use, I'll just leave it that way. The second, isn't that my old UID? I don't remember. The third ID number changes often, just a counter of some sorts? What now, do I have to update each mention of my old UID, home and hostname before I can use calenders and tasks again? \*sigh\* Well, it's worth a try, since I find no easier solution in newsgroups, either.

OK, after updating millions of %gconf.xml lines with the correct $HOME, $UID, $HOSTNAME entries, I open Evolution, and... Yay, the contact list wakes up from its beauty sleep. Then, Evo develops a Bad ConcienceTM and gives me like half a dozen popups for all those meetings that I have "missed" during the last 2 days due to "sudden invisibility". (Yeah, right, does Evo truely believe I trust a computer with reminding me? Kiss my analogue hardcopy, baby.) However, still no tasks nor meetings visible in the list, neither can I add new ones. Or can I? Adding a test task via the New Task menu item doesn't show any response (not even an error message). But when I double-click the task list, type "test test test" into the line, and hit enter — it shows up in the list! And with it, all the other old entries!? Yay! Evo blushes and quickly highlights all the tasks red that were due yesterday, just in case I didn't know.

Unfortunately, this "solution" only goes so far it seems, for the calender part still doesn't show anything even after I've added some test appointments. I look at the \*.ics — Strange, the test entries seem to have made it into the files... but are not displayed...? Well, to cut a long story short: If it should ever happen to you that some config ought to be working, but the data still doesn't show, check whether there is a filter or tiny checkbox somewhere that switches visibility on/off... \*whistles innocently\*

Now I sit here again happily hacking away with my Linux (well, as happy as one can be without Sylpheed), only interrupted now and then by an overeager Evo popping up little windows saying "Appoointment! test test test!" Shoot. Should have deleted those...

About

NetBeans IDE, Java SE and ME, 3D Games, Linux, Mac, Cocoa, Prague, Linguistics.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll