Unified autostart scripts directory
bastian at kde.org
Mon Jul 4 12:27:42 EEST 2005
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
> 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.
> - Questions raised: should we have a system wide directory where
> third parties can drop desktop files where their RPM/DEB/etc. is
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050704/3a35c5ae/attachment.pgp
More information about the xdg