Re: Gnome Session Services Framework

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2005-07-19 at 12:03 +0100, Mark McLoughlin wrote:
> 
> 1. Session Services vs. Session Managed Apps
> --------------------------------------------
> 
>   The idea here is that the concept of "saving session state" has no
> relevance to most of the programs which are currently controlled by
> the session manager using XSMP. Most of the programs are parts of the
> core desktop which have no "session state"; the state of these
> programs are controlled entirely by user preferences.
> 
>   The proposal is to coin a new term for these programs - "session
> services" - which sets them apart from applications which do have
> session state.
> 
there is still, for the nautilus case, I think, a case where we want the
service to save session state, so that it opens the same windows that
were open when the last session ended. So, maybe we need session
services to store session information also.

>     - apps contact gnome-keyring-daemon using a socket whose address
>       is specified in an environment variable[1], and so the daemon
>       gets launched very early so the env variable is set for all apps
> 
what would be much better, IMO, is to have applications using g-keyring
activate the daemon on demand, as we do for Bonobo components, D-BUS
services. Not sure how hard it would be to do it though.

> 
>   The implication here is that launching other session services or
> apps which are part of a saved session can happen once these essential
> services have been launched.
> 
I think we could have an 'order' field for services, like
for /etc/init.d services. Thus, we can specify, apart from the
dependencies, the order those services need to be started on, having a
low number for the essential services you mentioned above.

> 
> 7. Allow Switching Window Managers
> ----------------------------------
> 
>   If we didn't allow people to switch window managers, we'd be
> accused of some grand conspiracy or something, so we need to figure
> out how someone could choose for e.g. sawfish to be the "window
> manager service" rather than metacity.
> 
we can have generic service names, or a 'provides' field in the service
configuration. Thus, the panel could just depend on a generic window
manager service.


> 8. Allow the WM to Save Session State
> -------------------------------------
> 
>   When a user saves the session, the window manager saves the current
> positions, size, stacking order etc. of all open windows. If the
> window manager is no longer "session managed" itself, we need to
> figure out how to allow it to continue to perform this task.
> 
as I said, services would need to have a way of saving session data
also.

> 
> Other Considerations
> ====================
> 
>   - Should we have a way for admins/users to add non-managed, one-shot
>     "run this at login" programs?
> 
that would be a nice idea indeed, for things like initial user setup, we
can have a 'RunOnceOnly' field or something that makes gnome-session
store a GConf key once the service has been started once, so that it's
not started in subsequent logins.

>   - At logout, should the priority be to shut down quickly as
>     possible? Or should we ensure all services are shut down cleanly?
> 
I think we should ensure all services are shut down cleanly.
-- 
Rodrigo Moya <rodrigo gnome-db org>