Autostart (Was: Third-party sessioning requests)

[Ray Strode]

l.lunak at suse.cz wrote:

>  Actually that's mostly what the autostart condition is for. Apps
>  started this way specify RestartNever for SM, and use the autostart
>  condition to specify whether the app should be restarted or not.
That means every time these applications are loaded they are given
a new session id which they never reuse.  I guess I don't like this
much either.  It means that they are basically ignoring the
session manager for all persistent data.

>  I've never liked this much (but apparently not that much to make me
>  think about something better). This can get ever a bit more
>  complicated with the fact that many utilities which I believe should
>  be panel applets are systray apps, and even if the user decides not
>  to save KDE sessions, they still expect things that are "part" of the
>  panel stay in the panel even after KDE restart

You are saying that panels shouldn't save which panel objects need
be loaded as session id specific data, yea?  I'm not sure I agree with
this, but I think it is how both gnome and kde behave currently, so I
won't argue.  Certainly, though, it would be nice if applets and
apps that startup as only a systray icons behave the same way.

Tell me if I'm off base, but I think the situation is that the panel
handles when applets are started and stopped.  In this respect, the
panel is sort of its own session manager for its applets.  On the other
hand, apps with systray icons aren't started by the panel.  Instead,
they are full blown independent applications which are currently
started from autostart (conditionally).  I guess that's where the
problem is.  Like you said, one solution is to make these systray
programs into applets.  It's not entirely clear to me when a program
should be in the notification area and when it should be an applet,
but I guess that's a topic for a different thread.  Assuming there
are good use cases for applet-like systray programs then these
programs need to follow what the panel wants and not what the session
manager wants because to a user they are just like applets.

It seems then that the panel should handle starting and stopping
these programs just as it does for applets.  If we consider
autostart to be part of the session manager's domain then I guess
these types of program don't belong in autostart.  Tell me if you
disagree, and if you do I'll try to come up with something that will
make them work well in autostart.

>  (if you want to see something bizarre, start KDE, quit Klipper from
>  systray, say that you don't want it restarted, and later try to find
>  out how to re-add it permanently - things like this are the reason
>  why I don't like this way).
Well I installed kde and tried it.  It seems klipper has two versions:
an applet and a systray type program (am I right?).  Initially it was
an applet that I removed, I think.  Then when I ran it manually (versus
adding it through the panel) it was a systray program and I was able to
see the behavior you mention. I suppose for the systray version, the
only way to get around the problem would be to add it temporarily, then
immediately quit and then when it pops up the box that says "Restart on
next login?" choose "Yes".  That isn't very nice.  I suppose you could
have a preference "Restart on Login" which would work under the current
infrastructure, but like you mention, things just work nicer when
it's an applet.

>  I'm not sure if this would solve all cases though, we use the
 > condition even for KTip (i.e. whether to show a tip after KDE
 > startup).
Hmm.  KTip has a little check box "start on startup" or something,
yea?  I guess when it is checked then RestartStyleHint should be
RestartAnyway, but when its not checked then RestartStyleHint
should be RestartIfRunning.

The only problem is if the user doesn't save their session then
their choice will get reverted to the last saved session when
they logout, which is not a good situation.  The solution would be
for KTip to request that the session gets saved when the box gets
clicked.  Saving the entire session is bad obviously, though.  So, I
guess there needs to be a way for a client to request that its entry
in the session file gets saved without interfering with other clients.

Up until now session managers have responded to
SaveYourselfRequest (global = False) by just sending back a
SaveYourself message to the client.  On the other hand
session managers have responded to
SaveYourselfRequest (global = True, type = Local/Both) by sending
SaveYourself to all clients and also possibly writing data to the
session file.  Correct?

Maybe we should add something to the DSME that says that the session
manager should also update its session file for
SaveYourselfRequest (global = False).  Of course, in this case it
would only update the session with the client that initiated the
request and keep all other clients in the session file the same.

>  This would of course require that the SM manager reads both its saved
>  session and the autostart directory and ignores the apps in the
>  autostart directory that are in the saved session. This would also
>  solve the problem how to specify what has to be started for the very
>  first time when you have nothing at all the session.
Yea.  That sounds good.  The only problem I forsee is identifying
a program in the session as equivalent to a program in the autostart
directory.  There is no guarantee that the RestartCommand of a saved
client will match (or even nearly match!) the Exec line of the
.desktop file (usually it will nearly match, of course).


> I think we could use 'autostart-after=<list>', and <list> would contain 
>either names 'kwin','kdesktop', etc., or roles/phases, written in some 
>special way, let's say '[WM]', '[SESSION]' etc. Apps would simply specify 
>everything they need to be started after,
>
Using a list sounds fine with me.  One concern I have is that
'[WM].desktop' is a legal name for a .desktop file, afaik, which could
potentially cause ambiguity. We have a few options I guess:

1) Make it two separate lists, e.g.,
   autostart-after: kwin; kdesktop;
   autostart-after-role: panel; normal;
2) ignore .desktop files with bracket inside the autostart directories
3) assume autostart-after values in brackets are roles, and then if
   no matching role is found, assume it is a .desktop file.
4) Make the .desktop suffix mandatory for .desktop entries, e.g.,

autostart-after=kwin.desktop; kdesktop.desktop; [panel]; [foo].desktop;

Which is your preference?  I'm open to any of the above.

--Ray