autostart spec updates/extensions

[Bastian, Waldo]

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

Fragile -> cumbersome.. you get the idea.

> 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).

If the app crashes it will no longer be part of the session.

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

Just as konqueror has a preloader, someone may want to preload OO.o for
example. An application like skype may want to have a small daemon that
listens for incoming connections and start the main app to handle
incoming calls. Those aren't desktop components.

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

Which at the same time introduces panel-like problems, take
konsole.desktop for example: changing the Exec=konsole line to
Exec=xterm without changing X-DCOP-ServiceType results in funky
behavior. If you change one part and then later a system upgrade changes
another part of the .desktop file the result is quite unpredictable.

>- compatibility with KDE?

It's a subset of what KDE does and as such is perfectly compatible. KDE
can continue doing what it does now, tools like kiosktool shoud just
make sure to use lockdown for autostart files in the way that this new
spec would prescribe. (Using [$i] on a line by itself.) KDE already
supports that just fine.

>- possibility to have a lockdown (assuming you don't write a new system
>from scratch again)?

Using [$i] on a line by itself provides all the lockdown you will
practically need. For autostart it makes very little sense to be able to
lock down a single line in the .desktop file, for the very same reason
that it isn't a good idea to change one line in the .desktop file and
inherit the rest from the parent.

Cheers,
Waldo