Go forward in time to December 2004.
I've been working on pulling out interesting bits from GTK+ HEAD to put them in the 2.4.13 stable release, at least for our Novell package. These bits of course include typeahead in the file chooser. I'd also like to include things like the update counter for GDK. However, the diff between 2.4.13 and HEAD is 20,000 lines long...
For the people who are talking about version control systems: it would be useful to commit a patch and say, "this patch refers to FEATURE-FOO". All commits pertaining to typeahead in gtktreeview, or about gradually improving some aspect of the library, would get the appropriate tags. Then one would be able to ask the version control system, "give me a mega-patch for FEATURE-FOO".
Tomorrow I'm going to Veracruz for GULEV 2004, where I'll be giving two talks.
Back to hacking on the file chooser. I put in the patch in bug #155744 to try to load as much as it can of a folder within half a second, and later set the tree model. This certainly helps the visual appearance, as for most directories there is no visual re-sorting and shuffling of files. But it still takes a long time to load largish directories like /dev, while, say, the Midnight Commander is virtually instantaneous: GtkFileChooser takes about 7 seconds, and with MC you don't notice it.
GtkFileSystemModel starts an asynchronous load of a folder, and it gets lists of read-in filenames from a callback. It sorts that list and then merges it into its current list of files. As it merges each file, it emits a "row_inserted" signal — it has to, as it is an implementation of GtkTreeModel.
However, the file chooser uses a sort model on top of the file system model. So, sorting gets done twice, and in a fairly inefficient fashion. GtkTreeModelSort takes each newly-inserted row, does a binary search on its own data to see where to insert the row, and then grows its array of data. In the end it's all O(n²).
Some time ago I was wondering whether there may be some additional slowdown in gnome-vfs's asynchronous loading functions. They are actually fast: /dev gets loaded in 0.19 seconds on my machine.
I think the right steps to solve this problem are these:
Apply the patch in bug #155744 to delay setting the tree model on the tree view. This gives us an immediate win, as users will get a better appearance out of the file chooser.
Make GtkFileSystemModel implement the GtkTreeSortable interface on its own, rather than using a GtkTreeModelSort on top of it. This will let us have a good data structure inside and keep control of when things get committed upwards to the tree view. This will of course take some more time.
Nat pointed the NLD hackers to some really nice performance work that is being done in Fedora since Owen's challenge to do a time plot of the boot sequence. The first results came in a few days ago, courtesy of some Eastern European freak genius, as usual. Look at 'em sexy charts! This may be old news for people following Fedora development, but it put me in a very good mood today.
I spent last week in the city of Foz do Iguaçu, in Brazil, to attend the I Forum Gnome. On Thursday I gave the usual talk talk on the History of Gnome (which started out as a recycled version of Michael's and Miguel's excellent versions), and on Friday I gave a tutorial on Mono/Gtk-sharp/Glade programming. Had a chance to meet Everaldo Canuto, who gave another similar tutorial — hopefully we were able to reach more programmers that way, as the makeshift conference rooms were very small. It's good to know that our talks were among the most crowded :)
One gentleman from Peru was very intent on asking about RAD tools for Gnome. He wants to put applications together very quickly: databases, some email stuff, some GUI stuff. That's bread-and-butter with MS's Visual-* tools, or with things like Delphi. So his questions around my tutorial revolved around "why can't Glade generate most of my source code", "why doesn't Glade let me plug into a database", "where do I get a fully integrated IDE"...
Another gentleman from Brasil uses this DOS-based programming language called Dataflex. You define data-entry screens with ASCII art:
Name: ________________________ Date: __/___/____
And that goes directly in your source code. Then, you write something like
set value 0 to "Federico Mena" set value 1 to 12 set value 2 to "nov" set value 3 to 2004
Then it looks like it's really easy to plug that into a database.
Over the 2.x series in Gnome we've paid a lot of attention to users. We should start thinking about everyday, non-l33t hax0r programmers: they need good, easy tools to let them build applications quickly.
My friend Sandino has been writing some cool utilities and tutorials for Pygtk hackers. He just wrote a nifty tutorial on using Glade and Python.
For the long weekend we went to Mexico City. We drove back yesterday in the afternoon, but we were really tired on the way. So, we stopped for the night at the minuscule town of San Salvador El Seco. Today is the Day of the Dead in Mexico, an very important holiday, and people were busy setting up flowers and offerings at the cemetery. There was a thick fog covering the town. Oralia and I went to look around the cemetery before resuming our journey back to Xalapa.
Go backward in time to October 2004.Federico Mena-Quintero <firstname.lastname@example.org> Tue 2004/Nov/02 18:13:01 CST