How does ksmserver start applications?

[Lubos Lunak]

On Tuesday 27 August 2002 19:02, Roland Seuhs wrote:
> Am Dienstag, 27. August 2002 18:17 schrieb Lubos Lunak:
> > On Tuesday 27 August 2002 14:14, Roland Seuhs wrote:
> > > > > > On Tuesday 27 August 2002 12:26, Lubos Lunak wrote:
> > > >
> > > > Yes, it's handled by KWin. KWin asks X to redirect window mapping to
> > > > KWin, and before the window is actually shown, KWin applies geometry,
> > > > etc. saved from the session. And no, your application cannot do the
> > > > same, it'd have to ask KWin to do it (e.g. now placing windows of
> > > > newly started app on the desktop they were started on is handled this
> > > > way - but I guess it refuses to use non-existing virtual desktop).
> > >
> > > I don't understand, why can't my app tell KWin?
> >
> >  Since right now there's no such support for it in KWin.
>
> Does KWin only accept these commands during start-up?
>
> If ksmserver can issue these commands, every app should be able to, no?

 Ksmserver doesn't issue any commands to KWin. It simply starts the apps and 
KWin checks for new appearing windows and maps(=shows) them according to its 
saved session data.

>
> >  I'd say it's actually the system (kernel etc.) itself that should handle
> > it (and that's why we have kdeinit and other hacks, right? :-/ ).
>
> Well, the kernel simply can't handle it.
> Most apps load configuration files on startup, they load icons, pictures,
> etc. I don't see any other way of caching all that.
>
> > > If I can somehow overcome the focus-problem, I think this app will make
> > > KDE usable for many users which find KDE currently too slow. A
> > > KDE/Linux system caches data on so many levels (CPU, disk-cache in RAM,
> > > disk-cache on HDD) why not cache whole apps to eliminate start-up time
> > > once and for all? Also, my app doesn't interfere with any other things
> > > in KDE.
> >
> >  Well, I personally don't like these details:
> > - this hidden app(s) will most probably get session managed just like
> > others, so it will make KDE startup time even longer (which is for many
> > people actually the reason they say KDE is slow).
>
> Come on, this is really a non-issue. A smart implementation (for example a
> simple "sleep(120)" before you start loading the apps and "sleep(5)" in
> between starting the apps) will not get noticed. (I know sleep() is not
> pretty, but who cares?) You could also check if there is enough RAM
> available to decide wether to cache an app or not.

 Yes, of course, no problem. You just need to find out how and where exactly 
to insert those sleep() calls, because without some ugly hacks, the session 
restoration will be completely out of the control of your utility. Those 
hidden apps will be saved on logout just like any other app, and they will be 
restored just like any other app. I don't know much about XSMP but I don't 
think you can force other apps to change their session-management status (I 
may be wrong here though).

>
> BTW, I think ksmserver should try to start one app after another and not
> all simultaneously. My machine crawls during startup.

 I think it does it that way in HEAD.

>
> > - the hidden app may eat some CPU time (not that much though I guess)
>
> I agree 100% that you shouldn't use ktop with it.
>
> > - it's not going to work reliably for all apps (they may e.g. popup a
> > modal dialog sometimes, which would look strange since the app is not
> > "running")
>
> If you can somehow get all window-ids for an app, this can be made to work.
> Otherwise just don't use it with that app.
>
> > - technically it's probably better to avoid hacks like 'hidden desktop
> > 16', and hide the window completely instead
>
> Maybe. But also a lot more complicated if I'm not completely wrong.

 I don't think so. It will be just hiding the window instead of putting in on 
non-existing desktop. No bit difference. Hmm, maybe except for not having a 
taskbar entry for it.

>
> > - this all will be IMHO just one big ugly hack
>
> Well, I really don't want to argue that because yes it probably is. However
> unlike many other hacks it is totally unrelated to the main project, so it
> won't be a problem for anybody and won't have any adverse effects on KDE's
> codebase. No developer will have to go through the pain to understand this
> hack. It's just that in some cases it will be useful, ugly hack be damned.
> It doesn't have any adverse effects to the codebase and you freely choose
> which apps start normally and which using the tool.

 I didn't say you are forbidden to do it. I also don't like the theory of 
relativity and other people don't give a damn about it :).

>
> >  Hmm, ok. Looks like nothing really preventing you from doing it :).
>
> If I can't get around the focus-issue, it is preventing me from doing it
> :-(
>
> > For
> > the focus problem, you can for now probably use doNotManage() from KWin's
> > DCOP interface, the argument is regexp for window title, first matching
> > window won't be shown. In case your utility shows to be really useful,
> > there can be written something better in KWin than this ugly (yes, you
> > guessed it) hack doNotManage().
>
> When the window already has a name, the focus is already stolen, so I don't
> see how that can possibly work.

 No, you don't understand. KWin can intercept showing of a window and do some 
actions with it before it's really shown (and only the WM can do that). Just 
run kdcop, use the doNotManage() KWin DCOP call and enter e.g. '.*KDCOP.*', 
then quit it and run it again - this time the window won't show.

-- 
Lubos Lunak
developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/