Re: Application launch detection

[raster rasterman com]

On 10 Nov, Peter Astrand scribbled:
->  
->  > 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. 

oh - dont check on creation - only check on map - created windows if
not mapped should be left alone by any "tool wait" program or wm or
whatever - only mapped windows (or windows that have a WM_STATE
property on them - ie window could be iconified)

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

controlling xlib either via an Ld_PRELOAD hack or via having a modified
Xlib or getting this modification into xfree86/X source is the most
desireable course of action - havingto wait for everyone to go
implimentit is not so desireable.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster rasterman com     raster valinux com
                                    raster enlightenment org raster linux com
				    raster zip com au