« October 2004 | Main | December 2004 »
November 15, 2004
Answers to some questions
Since my last blog entry I've gotten some questions; here's an attempt to try to answer them:
Why is GnomeProgram horrible?
There are a number of reasons why this is true:
- The API. The API is not language binding friendly, it's not even C friendly; it has lots of confusing functions and is plain weird.
- The argument parsing. GnomeProgram uses popt, but in a way that is both hard for the application programmer to use, and makes the end result look like something that would make Seth Nickell scream in horror. (Try "nautilus --help" to see for yourself for example)
- The implementation. Although this isn't really a problem for the users of the API, it gives the maintainer (me) a really bad headache. There are bugs in GnomeProgram that I've given up on, simply because they are impossible to fix. The GnomeProgram code also contains accessibility initialization code that should be in libgnomeui, but that's impossible because of the design. Ugh!
gtk_init_with_args should be enough, thanks to GOption. (I was going to link to the API documentation here, but gtk.org doesn't seem to be healthy)
Isn't making a flat dependency chain against the idea of code reuse?
No. I am definitely not arguing against code reuse. What I am against is libraries that depend on other libraries for no good reason. For example, libgnome has a config: moniker that was written in order to be able to use GConf as a Bonobo interface. No-one uses this moniker, and no-one ever have. Still, it makes libgnome depend on libbonobo. Is that a good example of code reuse? Not really...
What it all boils down to here is that if I want to use a basic widget such as an about dialog or icon list, I shouldn't be forced to depend on a dozen libraries for no good reason.
When will the gnome libraries be removed for real?
This can't happen before the next binary incompatible release of GNOME, which should be 3.0 or so. As no one knows what GNOME 3.0 will contain or when it will be out, the answer to that question is hard to give.
But isn't GTK+ starting to enforce policy? The file chooser uses the XDG MIME spec for example!
That is true, but just about all of those policies are well-defined XDG standards. There is however not XDG standards for everything yet. If you run KDE and click on an URL, you most likely want it to be opened in Konqueror, not Epiphany. Thus, until we have a good specification for launching default url handlers, GTK+ can't really do anything itself.
I hope this clears some things up.
Posted by Anders Carlsson at 12:13 AM | Comments (14)
November 14, 2004
Handling desktop integration
Motivation
As many of you already know, Jonathan and I are trying to deprecate more and more of the gnome libraries with every new major release of GNOME. Why is that?:
- Lack of library goals- Pretty much all of the libraries in the platform have a defined goal. GTK+ is for the user interface, libxml is for XML processing, GConf is for handling configuration. But what is libgnome and libgnomeui for? Right now they're a mix of broken widgets and code that wont' fit elsewhere
- Dependencies - The GNOME libraries are pretty high in the dependency chain. If you want to use GnomeIconList, you need to pull in (at least) GConf, libxml, ORBit, libbonobo, libgnome, libbonoboui. We would like a dependency chain that is more flat, especially now that less and less program are using Bonobo at all.
- API - A lot of the API in libgnomeui is at least 5(!) years old. We've learned a lot about API design since then.
Desktop integration
One of the most horrible parts of libgnome is GnomeProgram; the code that handles start-up and argument parsing for GNOME programs. This code also sets up the program to be more "integrated" with the rest of GNOME. For example, when your application segfaults you get this nice dialog allowing you to report a bug. When you have accessibility enabled, GnomeProgram calls the necessary hooks for that. All that is done by GnomeProgram.
Also, in GTK+ 2.6 there are more hooks that need to be filled by someone, for example
gtk_about_dialog_set_url_hook
which lets you set a callback function that will be called when an URL is clicked in the new GTK+ about dialog. In GNOME, this would open your default web browser with that link. Remember that GTK+ shouldn't enforce policy about what desktop the user is running. Since we're getting more high-level widgets in GTK+, expect more hooks of this type.
So how would all this be taken care of in a world without GnomeProgram? First of all, what is the difference between a GNOME program and a GTK+ program running in the GNOME desktop environment? Why shouldn't all GTK+ applications get a segfault dialog or be accessible? And how should all this be done?
I'll cover what I think is the answer in my next post. Stay tuned!
Posted by Anders Carlsson at 12:36 PM | Comments (20)