Re: Consolidating Core Desktop libraries

[Giovanni Campagna <scampa giovanni gmail com>]

Il giorno ven, 12/11/2010 alle 20.54 +0000, Bastien Nocera ha scritto:
> 
> There are reasons why all those are separate, and I think we should
> remember that.

I see two reasons:
- they have different purposes.
- they have been developed by different people at different times.

IMHO, reason 1 is not enough, given the example set by Gio (has GFile,
GIcon, GAppInfo, GDBusConnection, all in a library), and reason 2
doesn't really hold.

> > 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
> > breakages.
> 
> That's 2 users of the library, there's a similar one in Totem. But
those
> will be going away when we get those sort of notifications into the
> shell directly.
> 
IIRC, it is not planned to port GsdOsdWindow in gnome-shell, not in this
cycle at least.


> > 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 we need to make accountsservice more stable. And it could
probably
> ship a small library as well.
> 
But why having a separate library when the only possible users already
link to gnome-desktop?
(It is not that KDE would use libaccountsservice-glib...)



> I'm really not interested in seeing library aggregation of that sort.
> We're striving to get rid of most of those, and they will disappear in
> due time.
> 
But why getting rid of what works, and works cleanly and beautifully?
Instead we should make it more powerful and more used. This is the point
of having an Extended Platform, and a similar point goes for
libgnome-desktop.

And if it were me, we'd kill gnome-desktop (as a library), and
> copy/paste the very few bits between the modules that need it.
> 
And if it were me, I'd ship gnome-desktop and link it statically.
No really, copy/pasting makes it difficult to track changes, to fix
bugs, to port code, and results in duplicated object code in our users'
hard drives.


> There's currently RandR helpers (g-s-d and control-center), wallpaper
> handling code (g-s-d, control-center and nautilus), and the
thumbnailer
> (nautilus only, afaik).
> 
Add gnome-shell to the users of GnomeRR (pending bug 634332).


> The RandR stuff could be moved in g-s-d, and the wallpaper code as
well,
> when nautilus stops handling the desktop at some point in GNOME 3. And
> nautilus could move the thumbnailer code to use itself.
> >
Then gnome-desktop would only be a location for gnome-about.
> 
And we will invent a new tiny module every time we need some feature
across the desktop (I'm thinking of gsettings-desktop-schemas) or we
will hope for maintainers to be kind and update their code.

I'm not sure this is really the way forward.
(But in the end, it's not that I maintain anything, just I would find it
cleaner to have some sort of desktop platform with everything you need.)

Giovanni