[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Application launch detection

> 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

I agree with most of your conclusions. Just some small comments:

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

One must be careful when checking for atoms on newly created windows, if
the property is not set on all windows. If an application:

1) Creates an subwindow to the root window
2) Creates several subwindows to this window
3) Finally sets some atom on the last window

...it's not possible to reliable detect the property. Why? Because we have
to do XSelectInput on the subwindows, but new subwindows can be created
before we do XSelectInput. There is a note about this problem in the
xtoolwait(1) sourcecode.

So, either apps should set the property on all windows or the first one
(eg. it's enough to do XSelectInput on the root window. 

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

True. But we can control Xlib, sort of, and it means an solution that
works with all apps. That is the only reason why I'm hanging on to the
Xlib/LD_PRELOAD approaches...

/Peter Astrand <astrand lysator liu se>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]