Re: Application launch detection

[Rik Hemsley <rik kde org>]

I tried several different methods while looking for the best system
for app-starting indication. Each of these methods were checked into
the KDE CVS and given thorough testing.

Using the feedback I got, I settled on our current system.

Here's a description of the steps I went through. This might be
useful to those implementing something similar and for coming up
with a standard.

1) I tried using the Window Maker -style method of looking at the
   WM_CLASS atom on new windows. In theory, apps set the res_name
   part of the XClassHint struct to the application binary name.

   In practice, however, this isn't perfect. Setting res_name ==
   binary name is not a standard, and simply isn't done by many
   apps. Netscape Communicator is a good example.

   To try to work around this, I added an entry to the desktop files
   of apps that don't set WM_CLASS as expected. For Netscape
   Communicator, I had something like X-ResName=Navigator.

   This worked well, but it requires having a desktop file for
   any non-compliant apps. I'm sure you can see that this requires
   being able to see into the future.

2) I looked at xalf, to see if we could employ similar principles.
   The idea is simply to preload a tiny library which overrides
   symbols XMapWindow and XMapRaised. When an application calls
   XMapWindow or XMapRaised, you can then send out some kind of
   signal, set a property on the window, etc. You then call the
   original implementation, so there is no difference in behaviour.

   This approach also works well, but it has some major drawbacks.
   If you run a libc5 binary on a libc6-based Linux system, your
   application crashes. If you run a Linux binary on a FreeBSD
   system, your application crashes.

   There are ways to work around this, but none are satisfactory.
   For example, you could try to test which C library the app
   links to. Unfortunately the 'app' may in fact be a shell script.
   You can add a note to the app's .desktop file, but this doesn't
   help for apps which you don't have .desktop files for.

   Having applications crash due to your app-starting mechanism
   getting in the way was not acceptable.

3) The NET spec suggests that applications should set _NET_WM_PID
   on windows to their pid. This is slightly dodgy as window !=
   process, but it's certainly handy.

   By adding a few simple lines to KApplication's code (which is
   called by all KDE applications) I was able to set _NET_WM_PID.
   Any process can look at newly mapped windows, so it was easy
   to check for _NET_WM_PID.

   The only problem with this approach is that you need apps to
   support it. Just using _NET_WM_PID would have worked fine for
   all KDE apps, but all other apps would not work.

The approach I settled on for KDE 2.0 release is a mix of 1 and 3.
It causes no problems and I haven't yet found an application it
doesn't work with.

I would have liked a perfect system, but unfortunately we can't
control how people write their applications.

Rik