autostart spec updates/extensions

[Lubos Lunak]

On Monday 16 October 2006 20:37, Bastian, Waldo wrote:
> > The autostart spec should first define its relation to XSMP. Which
>
> usage
>
> >cases for autostart do you see besides initializing/launching desktop
> >components? And of course, hacked in manual session management in apps
>
> that
>
> >looks a lot like what XSMP should do?
>
> I think the main use cases for autostart are for things that dock into
> the panel on one hand and daemon components of applications on the
> other, essentially the kind of functionality that KDE applications use
> KDED components for. XSMP isn't particular useful for any of this
> because the whole process of becoming and staying part of a XSMP session
> is way too fragile.

 What exactly should be fragile there? The process of becoming part of the 
session can't be, because it's not there at all - the app has to be launched 
somehow for the first time and that's where autostart could be useful, yes. 

 Staying part of the session is more or less automatic, when the toolkit takes 
care of that. Certainly simpler than doing it manually (especially when it's 
not supposed to get so awfully messed up like e.g. with Klipper).

 I don't know what you mean with daemon components of applications, I don't 
see why there should be daemons of unused applications running (like the 
annoying KOrganizer systray thingy), but if you mean desktop components, then 
yes.

> >> > I have another question: should a .desktop file in
>
> .config/autostart/
>
> >> > be able to depend on the content of another one in
> >> > /etc/xdg/autostart?
> >>
> >> The spec says no, you only look at the file in the highest-priority
> >> directory, and ignore the other one completely. So if you create a
> >> personal autostart file that's a modified version of a global one,
>
> you
>
> >> should copy the entire .desktop file and make the changes you want,
> >> rather than only writing out the diffs.
> >
> > As already mentioned, that seems very wrong.
>
> I think it's a very sensible approach. KDE writes out partial changes
> for its panel buttons and that causes major problems, the problem isn't
> so big with autostart files

 The problem isn't at all with autostart files AFAICS. The problem with panel 
config is that it writes numbered config groups and there the merging is of 
course wrong (although I don't see why just deleting the group first doesn't 
take care of it, that looks like a bug to me). Autostart files don't have any 
groups like this.

> , but still it makes things a whole lot more complicated for hardly any
> gain.

- picking up later changes in the global file?
- compatibility with KDE?
- possibility to have a lockdown (assuming you don't write a new system from 
scratch again)?

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz