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

Re: Application launch detection

On 11 Nov, Peter Astrand scribbled:
->  > I think hacking this into XMapWindow is simply wrong:
->  > 
->  >  - Functions like MapWindow are wrappers around the X wire
->  >    protocol. When I say, XMapWindow(), I mean "map the window on the
->  >    server".  Xlib is not there to make interpretations of what I mean
->  >    and send extra events around or set extra properties.
->  We want to stop the feedback indicator when "something shows up on the
->  screen". As far as i know, this corresponds fairly well with the call to
->  XMapWindow(). We don't want to change the semantics of XMapWindow(), only
->  add a hook. I agree that we want to minimize extra events and properties,
->  but some technique is required. 

no need to add anything - apps can listen to mapnotifies or the wm
alreayd intercets map's and handles maprequests - so the important
thing is to have the property on the window by the time it reaches this

->  >  - XMapWindow has no idea whether the window it is mapping is
->  >    an immediate child of the root window, so I don't see how to
->  >    implement the modified XMapWindow without major slowdowns
->  >    or major changes to XLib.
->  It's sufficient to send the signal (or whatever) on the first
->  XMapWindow. In my demo code (see
->  http://www.lysator.liu.se/~astrand/projects/xalf/monitor.tar.gz), this is
->  done:
->  extern int                                                                                               
->  XMapWindow (Display* display, Window w)                                                                  
->  {                                                                                                        
->      int i;                                                                                               
->      /* Original function */                                                                                              
->      i = ((XMType)pfXMapWindow)(display, w);                                                              
->      send_signal(display, w);                                                                             
->      return i;                                                                                            
->  }          
->  void                                                                                                     
->  send_signal(Display *dpy, Window w)                                                                      
->  {                                                                                                        
->      const char *id_string;                                                                               
->      id_string = getenv (ID_PROPERTY_NAME);                                                               
->      if (id_string && *id_string) {                                                                       
->          Atom xa_launch_id = XInternAtom(dpy, ID_PROPERTY_NAME, False);                                   
->          XClientMessageEvent xev;                                                                         
->          xev.type = ClientMessage;                                                                        
->          xev.window = w;                                                                                  
->          xev.message_type = xa_launch_id;                                                                 
->          xev.format = 8;                                                                                  
->          strncpy(xev.data.b, id_string, 20);                                                              
->          XSendEvent (dpy, DefaultRootWindow(dpy), False,
->  		SubstructureNotifyMask, (XEvent *) &xev);        
->          putenv (ID_PROPERTY_NAME "=");                                                                   
->      }                                                                                                    
->  } 
->  All subsequent calls to XMapWindow will have the penalty of doing:
->  id_string = getenv (ID_PROPERTY_NAME); if (id_string && *id_string) { }
->  but I think we can live with that. Afterall, an normal app just uses ten
->  or so calls to XMapWindow, it is not that much. 
->  >  - Changing what XMapWindow to set properties as well may cause
->  >    unexpected side effects such as PropertyNotify events that
->  >    could potentially break legacy apps.
->  Maybe, if we choose an property approach. My demo code above does not
->  suffer from this. The event showing up on the root window could be sent by
->  any application. 
->  >  - The first window being mapped may correspond very badly
->  >    to the idea of the app starting up.
->  Wrong. I'm using this in Xalf, and it works great. 

actually it depends on the window that's being mapped - lets just say
for now doing this at map time is a bad idea - we just need to get
properties ontot he window one way or another by the time it is mapped.
the mapping "signal" already exists (is you do it right).

->  > Now, if you wanted to change X[mb]SetWMProperties to handle setting
->  > the PID, that might make sense. After all, it is very closely related
->  > to what it is doing already. It might even be able to set the
->  > LAUNCH_ID property, if that is what we decide to use, though I believe
->  > that would interfere with toolkits doing more sophisticated things.
->  But not all applications call X[mb]SetWMProperties, or? Then this won't
->  work very well. 

perhaps own is right that we can overload the XSet*Properties(); calls
- i was originally thinking window creates and reparents as detecting a
create or reparent that woudl subsequently result in an application
toplevel being managed by a wm is a trivial affair (just check the
parent if it matches root, and the window is not input only and not
overide redirect) ad properties = but to eb tbest of my knowledge
hnearly all apps use the basic XSetWMProperties etc. calls - and thank
god gdk hasnt been written to bypass this yet (then we'd have to hack
more than one place). nearly every application sets a name and class at
a minimum - we could start overloading XSetClassHint(); I guess the
only questionis how we are goign to start overloading it - weshoudl
probably try and get as much of the NET_WM and DESKTOP hint stuff into
here as possible. i liked the idea of having generic environment
variables being able to be set as properties (this means the app doing
the fork & exec can set this up so as the specs expand new properties
can be set).

right now i think we have 3:
LAUNCH_ID - taken from environment variable
PROCESS_PID - call has to getpid() and set this

we can frocibly add calls to XSetWMClientMachine(); as in my expereicne
even though many apps use names & classes then dont universally set the
machine name - we can do it for them.

i also suggest for convenience we also do:

PARENT_PROCESS_ID - call uses getppid();
USER_ID - call uses getuid();
E_USER_ID - call uses geteuid();

these, though they can be gleaned from the pid - are handy and trivial
to get at this stage.

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

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