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

List:       kde-core-devel
Subject:    Apps startup wrapper ( was: Re: Hi - Why we don't use kdeinit_wrapper normal ?)
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2001-04-26 21:44:39
[Download RAW message or body]


 I actually have in my TODO something like this startup wrapper script, only 
a bit more powerful and also of course more complicated. It could do kdeinit 
loading, app-start notification and start_on_current_desktop for all apps 
where it makes sense. BTW, start_on_current_desktop would make using KDE on 
slower machines much more comfortable - all KDE apps start at least 5s here 
). I haven't actually tried it except for some very basic tests, but I think 
it should work.

 The basic idea is that another directory is created specially for startup 
scripts ( or links, actually ), and this directory is put in $PATH before all 
other KDE paths, so they get picked up before the real apps. And developers 
willing to do 'gdb application' simply don't set this dir in $PATH or use a 
small script which removes this dir from $PATH and then starts gdb.

 Now, a kcontrol module ( or whatever ) is started and it searches all 
executables in $PATH if it makes sense to use a wrapper for them ( well, 
basically something like 'if ldd $1 | grep libX11.so.6' ). It will also 
search its database for exceptions ( e.g. it doesn't make sense to use it for 
xdpyinfo even though it's linked against libX11, the user probably doesn't 
want to use it for some apps, and some apps don't set properly their flags 
used for app-start notification ( Netscape and WM_CLASS ... blah blah blah ). 
For every app that "deserves" a wrapper it then creates a symlink in this new 
directory pointing to something like kdeinit_wrapper that will do all the 
starting magic ( I'm not sure if this is not a potentional security hole when 
the user has a write access to a dir in $PATH ... probably root could create 
the links !? ).

 Ok, now the user simply types e.g. 'konqueror' and the wrapper will be 
actually started. It should probably only link against libc to make it start 
very fast ( app with empty main() linked only against libDCOP and libqt runs 
>0.5s on my k6/150 ), so it should probably only forward a 
request+data_about_the_app to let's say kdeinit ( in case kdeinit is running, 
otherwise it will simply find the real app binary in its database and exec() 
it ). Kdeinit will notify via DCOP anyone interested in app-start 
notification, will tell KWin to place this app's first window on the desktop 
active at that time ( I think this simply will have to be handled by a WM to 
be flicker-free ) and will start the app. It could be probably also used to 
get better app-starting notification if necessary ( e.g. when starting 
netscape tell everyone not only that it's starting but also how to detect the 
first window ) - there probably should be a class which would handle this and 
would be used in taskbar, kwin and other things interested in app-starting 
notification - it should probably also handle cases like multiple starting 
notifications for one app ( e.g. when the started app is actually a shell 
script and it calls another binary - this way it should be possible even to 
identify windows belonging to this app by WM_PID ).

 So that's kdeinit starting, app-start notification and 
start_on_current_desktop. Now there are of course some problems like 
different pid or the fact that the app in no more attached to the console. 
The console output support seems to be partially implemented in 
kdeinit_shell, and pid ( i.e. sending signals ) and things like quiting the 
app using ctrl+c can be simply handled by the wrapper ( i.e. the very first 
started wrapper app ), it will simply forward all signals it gets to the real 
app ( it gets the pid from kdeinit ). This can't be done for SIGKILL and 
SIGSTOP, but who cares, it's not actually that big problem. Also, the wrapper 
will wait for the real app to exit and only after that it will exit, so you 
get behaviour very similar to the one of the real app running in the konsole.

 Unless I overlooked something important, this should make kdeinit loading, 
app-start notification and start_on_current_desktop work acceptably for all 
apps, including KDE-unaware ones, those started directly from konsole, those 
started from minicli ( which apparently doesn't do app-start notification ), 
konqueror started using kfmclient ( again, no start notify ), blah blah. It 
should be also simple to disable it completely or only for some apps.

 So, any problems with this or comments ? And, in case you think it's a good 
idea, anybody willing to implement it ? I could probably write the kwin 
start_on_current_desktop part if necessary, but otherwise, I'd like to 
finally get rid of the ugly KHotKeys hack and replace it with something real 
for KDE2.2 , so I don't think I'll have time to write this before summer 
holiday.

 Btw, with the msec & konsole test described in one other post in this 
thread, I get ~2.9s vs ~1.9s . So if all this above can be done in less than 
a second, I'm happy with it.

 Lubos Lunak
--
 l.lunak@email.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli

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