Unified autostart scripts directory

[John (J5) Palmieri]

On Mon, 2005-07-04 at 11:27 +0200, Waldo Bastian wrote:
> On Saturday 02 July 2005 18:14, John (J5) Palmieri wrote
> >
> > Hey Waldo,
> >
> > I would like a brief overview of what KDE does.
> 
> * Dependency handling wrt other autostart services to ensure a specific 
> startup order (e.g. start panel before starting panel applet) This requires a 
> definition of when a service is finished starting up.

We use D-Bus for this and a ServiceStarted signal.  Startup notification
could be used in the simple case.  Of course at that point we need to
specify naming.  We use D-Bus names (e.g. org.gnome.Panel).

> * Conditional autostart: start is dependent on the value of a specified 
> boolean configuration key. This is hard to standardize though, as long as 
> there isn't a common configuration system.

Could be a new key in the ,desktop file.  I think we use enable=(TRUE|
FALSE) may want to add DEFAULT to take DE setting.

> * Whether to start the service before or after (xsm style) session 
> restoration.

Is this important?  Could we somehow use dependencies to do this instead
of a separate config?

> > Here is where I see we 
> > should start:
> >
> > - Agree upon a user directory where we can drop desktop files into for
> > starting up upon login.  This should be desktop independent and not
> > contain desktop dependent services as of yet (i.e. desktops should not
> > use this as their service starting framework, it should be for the user
> > only).  If a service is required for the desktop it shouldn't be user
> > visible anyway.
> 
> Ok.
> 
> >     - Questions raised: should we have a system wide directory where
> > third parties can drop desktop files where their RPM/DEB/etc. is
> > installed?
> 
> Yes, I would think so. 
> 
> > - Agree upon a wrapper executable name and command line switches.  We
> > need a wrapper to make things simpler when working with d-bus.  This is
> > a forward looking requirement for when there is a full service
> > framework.  Having a common wrapper interface allows services to be
> > integrated into a desktop's framework without the service having to know
> > anything about that framework.  The wrapper is the liaison, knowing how
> > to talk with the system and exec the service.
> 
> I'm not sure I follow this, to what extent is a .desktop file with a Exec= 
> line not sufficient? Or do you mean that you want a wrapper executable to 
> access dbus service activation?

Yes, the wrapper allows activation without having to add an activation
file somewhere.  It also allows a non-dbus aware services to still be
managed through our service manager (of course the wrapper falls short
for services that fork and exit the main process).  The main point of
standardization here is for third parties who want to install their
stuff and have it work on all desktops.  The wrapper would allow us to
give them that ability while still integrating with the service
framework without having to know a bit about it.  We could punt this
issue for now but just wanted to throw it out there as part of what we
are doing for GNOME. 

-- 
John (J5) Palmieri <johnp at redhat.com>