No one and nothing is perfect, including GNOME. Version 2 contains many improvements introduced since the GNOME 1 days. However, backward binary compatibility is very important to GNOME, so you don't have to worry about your version 2 executables breaking; any program that works under GNOME 2.0 works with GNOME 2.2, and so on, up until GNOME version 3.0. In addition, your source code should compile without a problem. Progressive releases after a major release improve usability and fix bugs rather than expand the API.
GNOME 2 has an auxiliary library called libegg, for testing new features. Everything in libegg is supposed to go back into the main GNOME release; however, it's sometimes difficult to tell exactly when a change actually does make it into an upcoming release.
GtkToolbar will have a replacement widget sometime in the future. The main reason is that the items inside GtkToolbar aren't really child widgets; you need special functions to manage them. In addition, the toolbar has some other problems that need to be fixed, such as the mixing of buttons with and without labels and the interaction of the toolbar with windows that are narrower than the toolbar itself.
The powerful GtkTreeView widget is getting a makeover. Plans include better cell rendering (for data types such as images), better keyboard operation, support for context menus , support for drag-and-drop operation for multiple entries, the ability to sort entries based on certain criteria, and the ability to save the tree view configuration (that is, the node position and currently expanded nodes).
There's plenty of work to do on GnomeDateEdit . Current problems include GNOME's inability to store a 24- hour time and week start preference for the user and its inability to get or set dates before 1970 because the API works with Unix time. In addition, you can get only a full date; you can't pick out an individual piece such as the local time or a year. A new, more flexible widget should show up in libegg soon.
As you can see from Section 8.7, the mechanism for finding an icon that corresponds to a MIME type isn't terribly powerful. This is mostly because each MIME type can have several icons (several sizes in PNG format, an SVG version, and a set for each theme). Nautilus organizes its icons according to theme and current size , choosing the correct one for the user's settings; gnome_vfs_get_icon() , on the other hand, always returns the same name .
Work is currently in progress to resolve icon themes systemwide , not just in Nautilus.
A systemwide API for a list of recently opened files may make it into GNOME 2.6. There are some programs that already use this functionality in the GNOME CVS tree; of course, they must link against libegg.
The GTK+ file browser is a nagging topic among GNOME developers. The browser is unsatisfactory, but not so awful that it screams for replacement. However, a long discussion has provided many ideas on how to improve the file browser. Therefore, a new widget may appear sometime in the future, most likely in GTK+ 2.4. This rework of the GTK+ widget will be able to plug in to the GNOME infrastructure (GnomeVFS and MIME type icons in particular), but will also stand on its own for pure GTK+ applications.
Still being debated is how the new file browser dialog should actually appear. There are as many opinions as there are people discussing the matter, and the proposals are far from similar.
At the moment, GNOME uses the Enlightened Sound Daemon (ESD) to play system sounds. It works, but that's about the only nice thing that you can say about ESD.
ESD replacement is as persistent a topic as creation of a new file browser dialog. The current discussion includes GStreamer (a GNOME sibling project) and the new X11 Media Application Server (MAS). Both are modular systems that can do quite a bit more than play sounds.