Go forward in time to June 2005.
Sources for the cool Nokia/Maemo stuff. Their modified GTK+ package. Their hildon-fm package is what contains their custom HildonFileChooserDialog (API reference docs for HildonFileChooserDialog).
In their hacked file chooser, they cut&paste the declaration for GtkFileChooserIface from gtkfilechooserprivate.h, and then they implement their custom chooser using that GObject interface. In the end, Hildon programmers can use the normal gtk_file_chooser_*() API on a HildonFileChooserDialog, just like they would for a normal GtkFileChooserDialog.
They need to cut&paste the interface declaration into their implementation, because the gtkfilechooserprivate.h is a private GTK+ header which does not get installed. In GTK+ we should probably just rename that file to gtkfilechooseriface.h and install it publicly. The really internal stuff like GtkFileChooserEmbedIface, which we use for communication between GtkFileChooserWidget and GtkFileChooserDialog, can safely remain private.
One of the original ideas behind the file chooser was that one would be able to replace the file chooser with a platform-native one, while preserving the API. This is effectively what Nokia is doing.
There's a great document about how to port an existing application to Maemo, and how to make it run well on the Nokia handheld in particular. What is great about the document is that they take a real application, Gaim, and they describe exactly what they needed to change: make widgets smaller, re-arrange some widgets to make better use of the small screen, making auto-login mandatory and fixing the GUI for that...
Mathrick pointed out another interesting thing about Maemo's GTK+ package: they added an ::insensitive_press signal to GtkWidget, which happens when you tap on an insensitive widget. They use this for things like popping up a tooltip which tells you why the widget is disabled ("You can't do Edit/Cut until you select some text").
The problem is that right now GtkTooltips don't appear if the underlying widget is insensitive. I wonder if it would be better to add something like gtk_tooltips_set_tip_when_insensitive().
Update: the flaky machine is still alive after a day of having replaced the motherboard battery. I had no idea that an old battery would be so problematic; I used to think that only the hardware clock would lose the correct time.
I hate hardware.
The five year-old machine that connects our house to the net, and which is also our LUG's web and CVS server, recently started rebooting itself, or just hanging with no kernel messages. Yesterday Oralia and I took it apart, vacuumed each component and dusted it, and put it back together. It kept going down.
Today, in sequence, I changed these components, seeing if the machine became stable again after each step: power supply, RAM, and network cards — fortunately I had spare parts lying around for those. I even removed the unused sound card. It kept going down a few minutes after booting. Finally, I changed the motherboard's battery.
Let's see if it survives. So far it has a whopping uptime of 40 minutes, which is far longer than it has managed to stay up over the last few days.
Today I took a good amount of time in trying to figure out why Tab-completion and inline completion is annoying in the file chooser, while it is not annoying in, say, Emacs. I took some notes.
Terminology:
Tab completion is what happens when you hit the Tab key. Right now this is subtly different in Emacs and in the file chooser.
Inline completion is when the program automatically appends some text after the thing you are typing, and selects it. Whatever you type next will overwrite the selection.
An "open" mode is one where you can only select existing files or folders. In GtkFileChooser's terms, this is its OPEN or SELECT_FOLDER actions.
A "save" mode is one where you can select file names which don't exist yet. This is the SAVE or CREATE_FOLDER actions in GtkFileChooser.
Interactive search is when the file list in GtkFileChooser has the focus, and you start typing something. The file chooser pops up a little window with the contents of what you typed and jumps to the first file that matches — this is standard behavior for GtkTreeView.
Completion in Emacs:
Emacs doesn't do inline completion: it doesn't insert a suffix and select it so that anything you type will subsequently replace it.
You must explicitly hit Tab to complete. When you hit Tab, three things can happen:
There are zero matches. You get a beep.
There is one and only one match. Emacs completes its whole name for you. In addition, if this refers to a folder, Emacs appends a "/" so that you can start typing the name of a file inside that folder immediately.
There is more than one match. Emacs inserts the longest common prefix for all the matches. If you then hit Tab again, Emacs displays a list of all the files that share that prefix — but having to hit Tab again is irrelevant; it could just as well insert the longest common prefix and display the disambiguation list at the same time.
Completion in GtkFileChooser:
There is inline completion, where longest common prefixes get inserted and selected so that anything you type afterwards can overwrite the selection. We have inline completion because Windows people expect it. Inline completion happens as soon as you type something which unambiguously determines a common prefix. The prefix gets appended and selected.
When you hit Tab and there's an inline completion active, it gets de-selected and the cursor moves to the end of the text.
When there are one or more matches for what you have typed, the file chooser displays a drop-down list with the possible completions. You can select one with the arrow keys and Enter, or you can click on it.
Annoyances in the way completion in GtkFileChooser works right now:
Inline completion has been known to be over-zealous in SAVE or CREATE_FOLDER modes. There was a bug where inline completion would make it hard to type new file names which are a prefix of the completion. Matthias then fixed this so that in such a "save" mode, the file chooser would only do inline completion if you typed the unambiguous prefix for a folder. This is still not ideal, becaues you could have a folder called "foobar", but if you want to create a file named "foo", you get inline completion when you don't want it.
The solution is not to do inline completion for "save" modes unless explicitly requested. If the user hits Tab while in a "save" mode, then the file chooser should insert the longest common prefix matching what he has typed, and, if appropriate, present the drop-down with the disambiguation list.
In "open" modes, you want to do inline completion as soon as possible, because you can only open existing files anyway.
A minor annoyance is the bug where even if there is a single match, the drop-down appears, instead of just using inline completion.
A not-so-minor annoyance is that hitting Enter in the location dialog should close the whole file chooser.
Finally, the disambiguation list appears and disappears, which looks rather flickery.
Summary:
To be really nice, completion in the file chooser just needs to be a bit more explicit in the "save" modes. Also, confirming location dialog needs to confirm the whole file chooser, instead of simply returning to the latter.
All this came about because I was fixing CREATE_FOLDER mode. CREATE_FOLDER mode doesn't allow you to select an existing folder. Since this is directly related to the file name entry, I started looking at the other issues it has.
Sven: if you are implementing generic undo, take a look at Apple's undo framework. There may be some ideas worth stealing.
Ross is fixing memory leaks in evolution-data-server. Therefore, Ross is my hero.
Today I gave my little GTK# tutorial at the Facultad de EstadÃstica e Informática of the Universidad Veracruzana (those are old slides; I'll put up the updated ones soon). I was afraid that the audience would be totally lost in space like the last time. Students came from a background of being taught Pascal and C, and generally very little in terms of usefulness. Amazingly, this time people knew exactly what I was talking about, and they asked good questions. Most of the audience had never touched C# or GTK+, but they were familiar with Java. They had no problems picking up C# quickly from the examples I gave, or in reasoning about widgets and containers. My friend Gerardo Contreras, who is a teacher there and a free software enthusiast, has definitely put some hard work into the school. This made me very happy.
Alex has a good point: maintenance is not fun if you have to do it full-time. It becomes full-time when you are the only person, or one among very few, who knows a subsystem well enough to be able to make educated decisions about it.
This is partly a problem of documenting existing code. When people are able to get a high-level overview of a subsystem, then reading the code becomes much easier. For most parts of GNOME, though, we don't have that kind of overview. Who really knows how you are supposed to integrate threads, gnome-vfs, and authentication? Probably one or two people. Who really knows about how to use GtkIconFactory? Maybe the author — I've never seen an application go through the trouble of registering its own stock items and stock icons in a way that they'll follow the icon theme automatically.
If you are in frequent contact with the maintainers for modules then you can get a very good education through word-of-mouth. But what if you are a random developer? How are you supposed to learn all this stuff?
If we had better documentation about the internals of the different parts of GNOME, it would be easier for random contributors to jump in and do maintenance for us.
Our favorite Spanish restaurant in Xalapa just raised its prices for their standard soup-plus-main-course lunch. It was 39 pesos before, and now it is 47. The food is still great. It used to be that the portions were just of the right size that you would be satisfied, in terms of both belly-fullness and price. Now they just seem expensive. It's quite a shame; we enjoyed going there several times a week when we got lazy to cook.
Also, their ambient music has been declining in quality. They used to have good jazz; now it seems like Kenny G most of the time. And they changed their waiters: they are still students who work part-time, but the new ones never remember what you ordered, and they can't remember the things on the menu, either.
I had never read this long interview with Anders Hejlsberg, to which Miguel linked. It is a fantastic interview, completely full of wisdom. A.H. was one of my childhood heroes ("smart guy writes the Turbo Pascal compiler single-handedly in assembler!"). His interview is full of the feeling of experience and wisdom that one gets when you talk to a demigod such as Jim Gettys, and that's a good feeling.
Over the weekend Oralia and I took our bicycles to the lovely town of Tlacotalpan. It is flat, unlike Xalapa, and quiet and virtually car-less (definitely unlike Xalapa) so one can ride very comfortably and see the old houses. We have fallen completely in love with that town.
Oh, yes, and I have a new bike. I'm getting used to it after using the bike I borrowed from my brother a couple years ago. It's heavier, but has front shock absorbers.
Go backward in time to April 2005.
Federico Mena-Quintero <federico@gnome.org> Fri 2005/May/06 11:53:39 CDT