Platform, platform, platform (and integration!)
WARNING: Here follows a rant from a person without deep insight into the whole history of Gnome 2.0, but nonetheless feels qualified to give some constructive criticism.
Did anyone notice the 3 platforms in the title? That is no coincidence, because I am going to talk about platforms and my vision for Gnome 3.0.
It will serve you well to read Imendios vision of Gtk 3.0 before you read on.
Desktop and Platform?
- Platform: Rock stable functionality. API and ABI guarantes. If anything here breaks you get to spank us and call us animal names
- Desktop: If you have a dependency you don’t really know what to do about (and don’t like to #ifdef al lot) then lobby bit to convince people to put it here. These libraries should strive to remain API stable, but no guarantees given.
So the platform module sounds promising – how do you feel about the desktop module? Not too keen? Well some of the libs in desktop have individual API promises, but you get to figure that out for yourself. This project structure makes it very hard to get into platform (which is sane in this situation of course) and a lot easier to get into desktop.
Then you start skimming the list of platform modules (they do not appear in the listed order):
- glib – check
- gio – check
- gvfs – check
Very sane so far
- gtk+ – ofcourse, check
- 4 libs for dealing with Bonobo/Orbit – wtf?
- libart_lgpl – wtf? Don’t we have Cairo these days? Supposedly only used by the canvas widget.
- 4 seemingly Gnome-utility libs (libglade, libgnome, libgnomeui, libgnome-canvas) – wtf?
I must be frank an say that as an outsider (in the sense that I have not been part of the decision process) the Gnome stack looks a bit like a mess. Putting it bluntly, only GLib (and its modules) and Gtk really seem attractive. Gnome does not really feel like a “platform”, it feels like a collection of libs. There I said it. Sorry.
In short: More “plaform”, less “collection of libs”. Read on.
API and ABI Stability
As also proposed by Imendio (although mainly about Gtk+, where I am talking about the Gnome stacck) libs should not expose struct fields or other variables. Everything goes through getter and setter methods. This should make it a lot easier to maintain both API and ABI stability.
6 months for minor versions. 3 years for major versions. Why force a major version bump every three years? This is highly dependent on the Desktop, Platform, Core section below which you should read before flaming me. Other benefits of a forced 3 year major release cycle:
- Satisfy the feelings that the types of users and developers who want Gnome 3.0 now have. Note that this has nothing to do with the technical aspects – feelings are emphasized. If major releases make people happy I say we make them happy
- Selling point for distros. “Our brand spanking new version of FoobarLinux comes with the shiny new Gnome 220.127.116.11.5.1.4 as opposed to the the former release who shipped 18.104.22.168.5.1.3″, or sed that with s/22.214.171.124.5.1.4/4.0 and do the math on the total revenue
- Keep things moving. Give developers a window of opportunity to bring new technology into the stack. This is possible today, but it is more inspiring to push for a major release
The underlying idea here is to be more loose around the major releases because of human emotions not technical issues. We should not underestimate how important motivation is.
Desktop, Platform, Core
- Core: As platform today. Very hard to get in here, but with less cruft. Rock stable API adn ABI. Both are stable between major releases, this is more easy to maintain because of the new strategy noted under API and ABI Stability above. The idea is that other platforms such as XFCE or mobile platforms should also be able to depend on Gnome Core.
- Platform: API stable between major releases, not ABI stable. ABI stability is only per major release number. Proprietary applications depending on Platform will have to distribute binaries for each major release.
- Desktop: API and ABI stable per micro release (X.Y.*) in addition Gnome promises that the functionality in here is persistent for the whole major release cycle. Stuff might change API or even be moved to another lib, but you will still have a way to achieve the same effect without much hazzle.
Specifically for Core and Platform there is a “No Technology Leaking” policy. This means that we are not allowed to expose stuff from underlying libs such as X. Also for Platform and Core it is strictly verboten to stick application/lib-specific dependencies in here (libart, libeel). With Core and Platform you should be able to write just about any application. Desktop would contain the sugar to integrate with the official Gnome apps, and more specialized libs that a not of broad usage.
Namespacing – Especially for Core and Platform, but also to some extend for Desktop, we should be more aggressive about namespacing things under a g*-namespace. This gives a more coherent feeling. See for example libart, libbonobo, liborbit, libebook, et al. I realize that we cannot shovel everything into the g*-namespace, but can we just try harder?
Today Desktop contains cool stuff like GStreamer. Since GStreamer is not under the control of Gnome we can not really put it into Platform even though it might be cool to have there (if you don’t like the GStreamer example pick any other cool lib from the current Desktop module). To get such cool technologies into Platform or Core Gnome could be more aggresive with API indemnifying wrapper libs. While I am not sure I am all for what KDE has done with Phonon, a less aggressive solution could be fine to me. For example just creating a thin wrapper flexible enough to absorb underlying API flux, but not fat enough to flex out backends and other funkyness.
Specification, Abstraction, and Implementation
I am very exited about the “recent” trend of writing FDO specs and then implementing these (recent – like over the past years). I think we could a gain a lot from pulling more in that direction. Take for example the case of panel applets. If there where a clean specification for the construction and interactions with these then other platforms would have the opportunity to embed Gnome applets as well, without pulling in the whole stack. Since we are not allowed to leak underlying technologies we can not let the applet spec rely on XEmbed or X at all for that matter. Now who said GtkBuildable/DBus with some magic introspection glue? This could mean that Gnome applets could eventually run under KDE, XFCE or OS/X or WIndows.
Not all specs has to go through the FDO machinery. Gnome specific specs are also fine as long as they are stable like our APIs and respect our layering.
As also hinted in the paragraph about “API indemnifying wrapper libs“, abstracting out some of our dependencies could bring us a lot of flexibility and possibly a host of new developers. With the help of an officially adopted IDL writing thin abstraction libs could be made quite easy.
Just to make it clear about the proposed trinity of Gnome modules here’s a quick rundown of how it could look like:
- Core: Glib (and modules), Gtk+, Some dbus stuff, a networking lib, XML. Basic accessibility
- Platform: Lib for desktop search, and metadata management. GConf/DConf, libwnck, libxklavier, libgtop, gtksourceview, gstreamer, keyring etc. More advanced accesibility
- Desktop: Lib to remote control Nautilus and other high profile apps, specialized (for audio/video, or images, etc) metadata handling libs (exempi for instance), panel integration, libart, librsvg,
Thanks for following me this far. Let the public humiliation commence (remember I am allowed to dream ).
Update: Let me underline that I think we achieve a lot of this by using the codebase we have already. We need some extra spice (and IDL would come in handy) and then we’d probably need to break some API (not that much really) and remove a lot of deprecated modules. A lot of work, but not ridiculously much. Are we a team?