[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: How does ksmserver start applications?
From:       Roland Seuhs <roland () hasos ! com>
Date:       2002-08-27 17:02:17
[Download RAW message or body]

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?

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

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

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

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

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

Roland

-- 
Facts do not cease to exist when they are ignored.


[prev in list] [next in list] [prev in thread] [next in thread]