Re: Application launch detection

[raster rasterman com]

On 10 Nov, Peter Astrand scribbled:
->> ->  But: Are there *any* chance to get this extension into the official
->> ->  XFree86/OMG source? Is it desirable?
->> 
->> i think getting it into free86 wouldn't be too hard - and that would
->> solve nigh everyone's problems :) i'll have a chat with mark today and
->> see if there wouldn't be any objections.
-> 
-> Sounds good. People has told me Xfree86 uses the pristine OpenGroup
-> code. Do you know if this is true? In that case, maybe the Xfree86 team
-> are reluctant to make changes. 
-> 
-> But, assuming they are willing to make changes, we must specify exactly
-> what we want. People has wished, for example:
-> 
-> 1) Window property with PID. 
-> 2) Window property with machine hostname. 
-> 3) A mechanism transferring an environment variable to an window property
-> 4) A mechanism doing some signalling upon XMapwindow (via XSendEvent, for
-> example)
-> 
-> 1+2 is nice, but not perfect for app launch feedback, for reasons
-> discussed earlier (eg. scripts etc).
-> 
-> 3 is quite general, but as I wrote earlier, it's difficult to use for our
-> purposes. As I understand it, no reliable solution exists for detecting
-> such XChangeProperty events. I'm not an Xlib expert though...
-> 
-> 4 is best for app launch feedback, IMHO, 

agreed. though 3 is easy. xlib forcubly sets the strign contents of an
environment variable starting with let's say _X_ to a property of the
sane name on creation or reparenting of the widnow to root. (this should
cover all bases) - the way to handle this is as follows: tool alunch
status app sits and waits for creatnotifies on root. if it gets a
creatnotify of a window (you don't get piles of creates of windows
relative to root) - it checks the window attributes - if the window is
not override redirect, you grab the server - now check for any
properties yourare looking for - if they exist note their state for this
client window - seletc for property change notifes, and window destroys
and mapnotifies. ungrab server at this point. (if you have a batch of
windows in yoru que you can grab just once- do this per window in the
queue then ungrab) - now you will get events when things change. quite
happy. the WM can do ths too (infact the wm would only care about this
when it gets a maprequest or reparent - and since these properties are
set on creation/reparent time before the actual mapping or reparenting
the properties are guaranteed to be there). - window maps are alreayd
signalled for us either via maprequests in the WM (the wm can handle
this quite easily) or via mapnotifies (which will occur once the wm has
processed the map request and mapped the client window) - the only thing
i guess we need to get right is that wm's have a convention of keepign
iconfied windows mapped all the time (maybe not visible - but client
window needs to be mapped - parents do not need ot be).

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