Re: Application launch detection
- From: raster rasterman com
- To: astrand lysator liu se
- Cc: otaylor redhat com, hp redhat com, xdg-list freedesktop org, wm-spec-list gnome org, rik kde org, jirka 5z com
- Subject: Re: Application launch detection
- Date: Sat, 11 Nov 2000 12:58:31 -0800 (PST)
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
point.
-> > - 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]
