Unified autostart scripts directory

[Waldo Bastian]

On Saturday 02 July 2005 18:14, John (J5) Palmieri wrote:
> On Sat, 2005-07-02 at 13:30 +0200, Waldo Bastian wrote:
> > On Friday 01 July 2005 21:59, John (J5) Palmieri wrote:
> > > Having an autostart for simple programs and daemons sounds fine to me
> > > but I think there is a bit too much being put into this.  In order to
> > > have a true dependency system of which we are working on with
> > > libgnomeservice in gnome cvs, it gets a bit more complicated than just
> > > dropping a file in the right location.
> > >
> > > I think having a spec for easily dropping a desktop file in a common
> > > location to autostart a program is fine but I think we should let
> > > projects explore the more complicated stuff before writing up a spec
> > > that will please no one.  Projects have to define and find their needs
> > > before we can have a unified system.
> >
> > Within KDE we have a reasonable understanding what the needs are (for
> > KDE) and we have an implementation that meets those needs. With that
> > said, if you think it's more appropriate to limit the fd.o spec for now
> > to the "allowing a user to autostart programs they would like autostarted
> > in their session" use-case then that's ok with me.
> >
> > Cheers,
> > Waldo
>
> 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.
* 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.
* Whether to start the service before or after (xsm style) session 
restoration.

> 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?

> That is the first step requirements at least from the GNOME side.  It is
> simple and should produce a simple spec that everyone can follow.  It
> also allows for expansion and migration in the future.

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050704/3a35c5ae/attachment.pgp