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

List:       kde-devel
Subject:    App-starting notification. Request for comments.
From:       Rik Hemsley <rik () kde ! org>
Date:       2000-04-09 1:09:30
[Download RAW message or body]

Ok, app-starting feedback seems to be working nicely. When you
start an app with something that uses KRun (most stuff, like kicker's
menu, konqueror, etc, but not including konsole, minicli yet)
you get a taskbar entry in kicker immediately. It goes away when
the app maps a window.

If the app doesn't map a window within 20 seconds, the button goes
away anyway, assuming the app isn't going to map a window, or it's
a buggy app that doesn't set its window manager hints properly
to identify itself.

What I need from people is to be told when an app is buggy. So if
you start a program and it maps a window but you end up with the
extra taskbar entry staying until its 20 seconds is up, the app is
probably buggy.

You can test it by using xprop. If the app does actually set its
hints to something reasonable (e.g. Netscape Navigator sets its
res_name to 'Navigator' - which is wrong, because it should be
'netscape', but still usable) then I can fix it by setting
XClassHintResName in the app's desktop file, creating the desktop
file for kappfinder if necessary.

You can see the app's res_name by doing xprop, clicking on the
window and looking for 'WM_CLASS(STRING)' in the output. There
should be two strings.

For example, I get this for gvim:
WM_CLASS(STRING) = "VIM", "Vim"

So I have set XClassHintResName to 'VIM' in gvim.desktop. This
means that we can recognise that running the 'gvim' binary
actually leads to a window with a res_name of 'VIM', and kicker
can alter the 'starting' button accordingly, instead of it
just sitting there until timeout.

Any reports of buggy apps will be much appreciated and will give
us even more solid app-starting notification, better than anywhere
else :)

Rik

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