Consolidating Core Desktop libraries

Vincent asked me to send a mail to d-d-l about 	db82a33 in
gnome-desktop, that is: all libgnome-desktop include files have been
moved to $(includedir)/gnome-desktop-3.0/libgnome-desktop.
This is part of an other API break which is related to GnomeRR and

I consider this an occasion for a bigger discussion on redesigning
libgnome-desktop, moving forward from being the container of useful
libgnome parts, to the One Desktop Library.

We're in the middle of moduleset reorganization, drawing a stricter line
on what is core, and thus is expected to work only in GNOME and requires
GNOME and is required by GNOME, such wm, the panels, the control center,
the session daemons, and what is just an app using the GPlatform (GLib -
GIO - Gtk), which therefore will work on every G- desktop environment.

I believe this is the time for consolidating shared code used by this
core modules into a libgnome-desktop, the same way we killed libgnome
and merged useful features in Gtk / Gio.

There is a lot of code which is copy-pasted around our desktop. For
example, the GsdOsdWindow class, used by gnome-settings-daemon and
gnome-power-manager, had to be updated several times because of Gtk
Another piece of copy-pasted code is gdmuser, which lives in
gnome-panel, gdm and gnome-shell, and is constantly being updated
because of accountsservice instability.

Then there are microlibraries, killing which would help performance.
These include for example libgtop, libgweather and libgnomekbd, but also
liboobs if the system tool backends are not dead.
I can't find an use for them outside core desktop, while on the other
hand there are already core desktop packages that depend on them.

My proposal is then to take the classes included in these libraries or
copy pasted sources, move them to the Gnome C namespace (GnomeDesktop
GIR namespace) and add to libgnome-desktop.
API stability is not an issue, as we all know that
GNOME_DESKTOP_IS_UNSTABLE_API, and the only users of libgnome-desktop
should live in the desktop modulesets, so that if we ever break API,
we'll file patches before the affected maintainers even notices.

I'm looking forward to read your comments on this.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]