Unified autostart scripts directory

John (J5) Palmieri johnp at redhat.com
Tue Jul 5 23:44:47 EEST 2005


On Tue, 2005-07-05 at 20:35 +0000, seventh guardian wrote:
> >From: David Faure <dfaure at trolltech.com>
> >To: xdg at lists.freedesktop.org
> >Subject: Re: Unified autostart scripts directory
> >Date: Tue, 5 Jul 2005 20:21:21 +0200
> >
> >On Tuesday 05 July 2005 13:40, cobaco (aka Bart Cornelis) wrote:
> > > From comments elsewhere in the thread we seam to have the following for 
> >the
> > > different desktops:
> > > - KDE
> > >   $KDEDIRS/Autostart
> > >   $KDEDIRS/env
> >
> >Not really. We have ~/.kde/Autostart/ (by default, but it's configurable)
> >for the *user* autostart folder (i.e. it's empty by default but users can 
> >put
> >.desktop links, or shellscripts in there).
> >
> >And $KDEDIRS/share/autostart/ (which means a number of directories) for the
> >system autostart, with the features Waldo described. But starting 
> >KDE-desktop
> >apps in other environment doesn't make much sense ;)
> 
> Humm.. yes, I guess you're right on that.. We should focus only on the user 
> interaction stuff, like starting an im messenger on startup, 

Yes.

> or opening a 
> filemanager when a usbdisk is mounted, 

No - already solved

> or even what action to do when a key 
> is pressed.

Another spec all together.  I'm not convinced this is at all important. 

> Things like the "inner guts" of the DM should concern only the DM, and not 
> even being spec'd at all.

Eventually we may want a common interface for starting/stopping and
specifying services but for now DM's should just do what they do so we
can have more of a basis to define this in the future. 

> So maybe we should forget (at least for now) about the underlinigng dm's 
> services&stuff framework, and concentrate only in the "user side" of the 
> question?

Thats where I would like to see the focus end up.  There are things
there that we need to hash out but for the most part is easy for
everyone to agree on.

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




More information about the xdg mailing list