Go forward in time to March 2008.
Next week, March 03 to March 07, we'll hold a GtkFileChooser bug week in irc.freenode.net #opensuse-gnome.
What: We'll fix as many bugs in the file chooser as possible, review and merge pending patches from the GNOME bugzilla, and leave the file chooser in a beautiful state.
Who: WE NEED HACKERS AND TESTERS! See the wiki page for how to participate.
For GNOME in general: if you have patches for the file chooser in bugzilla.gnome.org that haven't been reviewed, integrated, or are generally just stalled there, this is the time to kick my ass. We'll update/integrate as many of those patches as possible.
In other, related news... I am almost done with fixing completion in the file chooser. I now have total gnosis of how completion should work, even with all the async loading, so that it will be fast, reliable, and smooth to use.
Get the git repo:
git clone http://www.gnome.org/~federico/git/gtk+.git
We are starting to organize Local User Groups for openSUSE. Join the discussion if you know other users of openSUSE within your area!
Nickolay Shmyrev is making a pretty interesting page on how to run GNOME on low-memory machines. Two hit-and-run thoughts... 1) What's with Spamassassin being the default in Evolution, when the Bogofilter plugin is sooooooo much faster? 2) That trick about symlinking locale directories to avoid disk seeks — is that something that could be fixed in gettext itself?
Today I needed to install the legendary SLED 10 to debug some stuff, but I had run out of partitions for the operating systems I normally have around for debugging purposes. Time to dip my toes in virtualization.
I used YaST's "create a virtual machine" module to install my first VM, ever — something akin to losing one's virginity. YaST installed the necessary packages, set up a disk image, read my installation ISOs correctly, and it Just Worked(tm). I'm really impressed! Mad props to those who made all the pieces work so smoothly.
Now I need more RAM for my VMs; I can see myself becoming a VM junkie if all works well.
My usual strategy for backups is to rsync my home directory from my laptop to my desktop box. This started to suck when the hard drive in the desktop box started getting rather full. So I thought, I'll get an external hard drive and figure out how to backup things properly.
Today I got a lovely 500 GB hard drive and an USB drive enclosure. It's black and shiny and has a pretty, reassuring blue LED on the front.
I plug the hard drive to the power, then to the USB port on my laptop, and I turn on the drive.
And nothing happens.
So I look at /var/log/messages. Sure enough, /dev/sdb appeared. But it has no partitions and it is not formatted.
I partition the drive, and format it (using YaST, since these days I can't be bothered to look up how to tell mke2fs to create a fucking ext3 filesystem).
I unplug and re-plug the USB cable to to the drive. An icon appears on my desktop, titled "500 GB Volume". Huh, I suppose I should have given it a name in YaST. Nautilus offers no way to rename it.
I double-click on the icon, and Nautilus brings up an empty window except for a lost+found directory.
So I drag some files to it. Ghetto backups, here we go!
And of course it tells me, You do not have permission to write to this folder. Root owns that partition, and I can't write to the hard drive I just purchased.
I guess the One Touch Backup button on the drive enclosure won't do much good...
Some time ago I wrote about annoyances with Tab completion in GtkFileChooser. I'm taking some time to fix things in the file chooser, with Tab completion being the first one.
The most annoying bug with Tab completion is that it doesn't work if the cursor is not at the end of the entry's text.
If you have "/home/fed" and the cursor is at the end, and you hit Tab, then the right thing happens: the text gets completed to "/home/federico/".
But if you have "/home/federico/photos/foo.jpg" and you move the cursor just to the left of the foo, and type th and hit Tab (expecting "thumbnails/" to be inserted), nothing happens. You also get this bug all the time in Firefox, when you do "Save link as": it suggests a reasonable filename in the file chooser ("lolcat.jpg"), but it invariably picks the wrong directory. You move the cursor to the beginning, intending to type "~/imagTab", but you get screwed because the file chooser won't do Tab completion in that situation.
This is because the code to do completion was pretty simple: it could only do completion if your cursor really was at the end of the text. This happens due to the way the code evolved. The file chooser's text entry keeps track of what you have typed so far, and when it looks like you have finished typing a directory name, it starts loading that directory asynchronously so that it can do completion on the filenames within that directory.
However, the code can't handle the situation when the cursor is in the middle of the text, instead of at the end: it would need to restart the "load a directory" process, based on the cursor's position, depending on which complete directory name is to the left of the cursor. But the code only changes the directory when the text changes, not when the cursor moves. It's crufty old code.
There's a lot of polish involved, so I'm dealing with things one by one:
The text entry starts loading the underlying folder as soon as it starts up, even if you never request completion. This is a performance problem.
The file chooser can't do completion until the underlying folder is loaded. If you hit Tab while the folder is still loading, you should get a hourglass cursor and possibly a beep ("I'm not ready yet").
The suggestion window for multiple matches should appear when you explicitly hit Tab, but only if there is more than one possible match.
You should get a beep if there are no matches when you request Tab completion.
I'm not convinced that GtkEntryCompletion has all the machinery it needs to be as polished as that, so some hammering may be needed...
In the panel, there are two main slowdowns at startup before the panel starts loading applets:
The first gap is where PanelToplevel does its initial size_request. What's making it slow? Some sub-widget is probably loading images or something... what is funny is that with either a cold or a warm startup, it takes around 0.4 seconds.
The second gap happens right after the panel enters gtk_main(). From there it takes a while (around 0.45 seconds) until the panel actually starts activating applets. I haven't hunted down all the intervening idle handlers, and kcachegrind doesn't seem to be cooperating to find the culprit.
This is the second instance of Novell Hack Week! I'll be profiling gnome-panel's startup to reduce our login time.
This is a timeline of gnome-panel during a warm startup:
The timings are not very good since this wasn't taken during a cold, full-session startup; I'll do that tomorrow. But there are some interesting things already:
The panel takes a good while to read its profile information, which is its current configuration. Why? This should just be reading a bunch of GConf keys and possibly creating some toplevel panel windows.
After entering the main loop, the panel takes a good while before it starts activating applets. Why?
Applets get activated in quick succession, and they reply asynchronously when they are ready. Tomboy, the Mixer applet, and the Notification Area are especially slow. Why?
You want to weigh your baby, but your bathroom scale doesn't have enough precision. What do you do?
First, take your wok and wash it.
Second, place the wok on your kitchen scale. Adjust the tare to zero.
Third, put the wok back on the table. Make it soft with a blanket and a pillow. Put your baby in the wok.
Fourth, carefully place the wok plus baby on the kitchen scale. Watch the balance! Write down the weight.
Fifth, bathe your baby. Take the clothes and the diaper and weigh them. Write down that amount as well.
Finally, make a simple calculation:
weight-of-baby = weight-of-clothed-baby - weight-of-clothes
Now that the wok and the baby are clean, you can start cooking. A 3.5 Kg baby serves six people.
Colin Walter has words of wisdom about optional components that should be mandatory in distros and our GNOME builds.
A while ago Josselin Mouette made the file chooser use single-click to activate shortcuts. This was a very nice change; it made the file chooser seem more responsive. Unfortunately, it also revealed a bit of stupidity on my part from a long time ago.
For some time I had the firm belief that the file chooser was very well "mouse-able", but that keyboard navigation was rather bad. So I made it do things that seemed reasonable at the time: make the focus change to the correct widget as you activate things, keep a focus beacon always visible...
When you activated a shortcut in the left-hand pane of the file chooser, it would automatically focus the file list. This made sense at the time: "you went to the place you wanted to go, so you now want to select a file, right?"
Unfortunately, this made the code pretty complex. Focusing the file list may cause a file to be actually selected. This can in turn wipe out what is in the Location entry and replace it with the newly-focused file. The effect is that the file chooser pulls the rug from under your feet at various times.
I just made a simple change that makes the file chooser not focus the file list when you activate a shortcut. This gives surprisingly good results... now, shortcut navigation seems smooth and predictable. These changes are now in the gtk+-2.12 branch and in the development branch.
Moral number 1: get the keyboard focus right, but don't try to be too smart about it.
Moral number 2: keyboard-able and mouse-able UIs are surprisingly hard to get right.
This code is
directly stolen from based
Code of Conduct. Thanks to the people who made it
These little clay chimneys...
... serve as exhaust for hot air, which collects at the top of the house in Oralia's super-cozy room-of-her-own...
... which overlooks the balcony on the side of our bedroom, and the garage.
To get to that little room, you climb the staircase (not built yet). The staircase volume is lined on one corner with glass blocks, which let in a lovely light at any time of the day.
... which in turn doubles as a waist-high surface in the balcony — which we'll be able to use to place cold drinks and other amenities for warm days.
The bathroom has a large window, which will sit above the bathtub (not built yet)...
... and that window lets us have a little wall with glass blocks to surround the shower, so that the shower will get light on two sides. This trick of perforated-inside-wall-next-to-a-window is shamelessly stolen from Joel's office.
Go backward in time to January 2008.Federico Mena-Quintero <firstname.lastname@example.org> Sat 2008/Feb/02 15:32:20 CST