Re: Plans for 2.20

[Rodrigo Moya <rodrigo novell com>]

On Wed, 2007-03-07 at 13:38 +0000, Bastien Nocera wrote:
> On Wed, 2007-03-07 at 10:48 +0100, Rodrigo Moya wrote:
> > On Tue, 2007-03-06 at 22:52 +0000, Bastien Nocera wrote:
> > > On Tue, 2007-03-06 at 10:53 +0100, Rodrigo Moya wrote:
> > > > Hi
> > > > 
> > > > So, it's time to start thinking about 2.20, since we have so many
> > > > changes we want to do. Here's a list of the things I've been collection
> > > > myself, to start the discussion:
> > > <snip>
> > > > * default apps:
> > > > 	- Merge with AT capplet
> > > > (http://bugzilla.gnome.org/show_bug.cgi?id=350263)
> > > > 	- Add package install/remove commands, to enable the Upgrade/Remove
> > > > items in the shell
> > > What's that for?
> > > 
> > for upgrading/removing installed applications. That's something slab
> > already has, that we disabled in upstream control-center, but that it
> > might make sense.
> 
> This is a distribution-wide setup, at worse, a GConf-only option. The
> user shouldn't have to choose, or be able to choose that. Distributions
> should set it up properly out-of-the-box.
> 
yeah, sounds you're right

> > > > * mouse:
> > > > 	- Move to an 'input methods' capplet?
> > > > 
> > > > * proxy settings:
> > > > 	- Extend it and call it 'Network'?
> > > > 	- Move it to NetworkManager or gnome-system-tools?
> > > 
> > > NetworkManager doesn't have any settings of its own, really. The proxy
> > > setting could host the multimedia network preferences (selection of
> > > "speed").
> > > 
> > what other network settings might make sense in this user-centered
> > capplet?
> 
> Maybe showing a list of the known NetworkManager networks, with the
> ability to remove some of them, as well as VPN configurations.
> 
good idea, although that would, somewhat, clash with nm-applet. But I
guess it doesn't harm to have the same thing accessed from 2 places (and
not everyone will run nm-applet)

> > > > - Theme capplet:
> > > > 	- Include mouse cursors as part of the theme settings
> > > > 	- Include font settings as part   "       "     "
> > > What's that last line?
> > > 
> > - INclude font settings as part of the theme settings
> > 
> > > > - Settings daemon:
> > > > 	- Consolidate all xrdb calls into one
> > > > (http://bugzilla.gnome.org/show_bug.cgi?id=314774)
> > > Unbreak the number of gdk_window_add_filter, there's just too many (and
> > > turning a11y on makes it install a filter that breaks other users of
> > > gdk_window_add_filter)
> > > 
> > I was thinking on structuring the different subsystems in g-s-d to be
> > more pluggable. That would allow 3rd party apps to install modules to be
> > started with g-s-d. That would help in cleaning up the code, quite messy
> > in some places right now. What do you think?
> 
> I think it's already hard to control what each part of g-s-d does while
> all the code is available to us. Using another daemon (similar to KDE's
> daemon-pluggable daemon) would be a better idea.
> 
well, that's what I suggest g-s-d to become, see attached doc.
-- 
Rodrigo Moya <rodrigo novell com>

Modular GNOME Settings daemon
=============================

GSD keeps growing, not only in size, but in complexity, as we add more and more things that
need to be started with the GNOME session. While some stuff (beagle search, etc) can be started
with the autostart feature in gnome-session, lots of other things need to be run at login
depending on settings, hence they make sense as part of the GSD.

To enable a better growing of GSD, and at the same time, to provide a mechanism for 3rd parties
to run code at login depending on preferences, here's a proposal for a new GSD architecture.

First, GSD should be simplified, by just having a main program that starts the basic things
(D-BUS interface, more about this later) and, once that is done, loads the different modules
from a well-known place (.so, maybe having the default ones compiled in) and initializes them.
For that, there could be an interface for modules to implement:

    interface GnomeSettingsModule {
	      initialize ();
	      run ();
	      shutdown ();
	      enable ();
	      disable ();
    }

So, when starting, GSD would load all modules and call their initialize() method. Once all is
setup, it would call the run() method, in which the modules would start the code that needs to
run during the session. Once GSD is going to terminate, it would call the shutdown() method.

Each service would have an accompanying GConf entry to specify whether it is enabled or
disabled and thus neither initialized nor run from GSD. All this should be transparent to the
module itself, and all managed by GSD.

This is planned to be used for the current "modules" that use this mechanism (init()/run()) in
the 2.18 version of GSD, but it could perfectly be used for all kinds of services. Thus, we'd
have a clear separation of apps started by the user and services, something that has been
discussed before. Services (screensaver, power manager, even the file manager) would just
need to provide a .so implementing the specified interface, and GSD would control the
enabling/disabling and starting/stopping of them.

D-Bus interface: GSD would have a D-Bus interface, so that other apps can make calls to it.

      interface GnomeSettingsDaemon {
		list listServices ();
		boolean isServiceEnabled (in string service_name);
		enableService (in string service_name);
		disableService (in string service_name);
      }

There is still the question of what to do with the current D-Bus interface for the keyboard.
I think it makes sense to keep it as part of the GnomeSettingsDaemon interface:

      interface GnomeSettingsDaemon {
		list listServices ();
		enableService (in string service_name);
		disableService (in string service_name);
		...
      }

Further development: Having a system-wide daemon that starts all needed services would allow us
to think about further uses, hoping for a better integration between all GNOME components. Thus:

   * Provide a single point for hardware discovery: we already use HAL so we could add methods
     to the GnomeSettingsDaemon interface to signal listeners about hardware changes.
   * Provide desktop-wide services: get/set known desktop-wide config entries, non-GConf settings
     change signals (like when the locale is changed, so that apps can change their locale on
     the fly, for instance)

This new GSD could provide an integration mechanism of lots of stuff that use different solutions
(GConf entries, adding/removing autostart files/desktop files, etc, etc)