Re: Application launch detection

[Owen Taylor <otaylor redhat com>]

Peter Astrand <astrand lysator liu se> writes:

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

It is common that apps do a lot of X traffic all at once, including
showing toplevel windows. So, sure, it probably will usually
work well.

But a smart app will actually typically map its child windows
_before_ it maps the toplevel. And there is no reason why an
app can't create a window, map the children, and sit there for
an arbitrary amount of time before showing the window.

A quick test with a Qt application where I commented out the
toplevel show indicated demonstrated that it was still calling
XMapWindow a few times. 

(GTK+ is a little more complicated because it has a separate "realize"
step, but its still very possible with GTK+ to have apps that map
child windows long before actually displaying anything to the
user.)
 
> 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. 

I have a hard time coming up with concrete examples of what this
will break, but I certainly know that for other calls to Xlib,
GDK occasionally depends on it doing _exactly_ what it is
supposed to, and nothing more or less. 

And note that extending your code to do anything more than
the simply "send an event to the root window" would break
things badly - if you generate a round trip to the X server,
or introduce the possibility of additional X errors, than
the breakage is no longer theoretical. So, by hacking into
XMapWindow in this way, you've severly constrained what
you can do in the future.

But you have also severly constrained what applications and 
toolkits can do, because if, using the extra information
available to them, they want to do a better implemenation
of LAUNCH_ID, then they have to know to unset LAUNCH_ID
before they first call XMapWindow(). That's not a clean
and maintainable API...

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

[...]

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

I think you'd find very few apps that do as few as 10 XMapWindow
requests. (Simply bringing up the empty toplevel window for Netscape
is about 45 XMapWindow requests)

But yes, I'd agree this amount of work won't make a big
impact on performance nowdays, GTK+ certainly does a lot more
complicated things around various X calls.

My objections to your approach, described as above, are more
that:

 - It isn't as good as what a toolkit can do, and it interferes
   with a toolkit doing it.

 - People do very sophisticated, and/or very foolhardy things
   on top of Xlib with the understanding that the interaction
   between Xlib and the server has simple, well-documented behavior
   that can be relied upon.

   X is not an easy system to understand all of, and guessing
   that "I'll just add an extra XSendEvent here and it won't 
   affect anything" is a dangerous thing to say.

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

[ see above ]
 
> > 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. 

True, though I think trying to make a one-size-fits all, magic, behind
the scenes implementation is doomed to failure in general.

> > Basically, don't try to put policy into Xlib, and especially not into
> > functions that are defined as wrappers around the X protocol - that is
> > the domain of the toolkit. If you want to hack X code, extend Xt, but
> > XMapWindow should not be changed.
> 
> The problem with extending Xt, GTK or QT is that there will always be
> thousand and thousands of applications and toolkits without this
> extension. Eg, this feedback mechanism will only work with perhaps 90% of
> the applications. This means that the desktop environment much decide
> if to use feedback or not - not an easy task. Including some flag in the
> .desktop file is probably the only way to do it. Not a clean solution. 

It's a lot _cleaner_ solution.... if we define a nice specification,
support will quickly become very common. We can start off with
assumming no notification, and using a MapNotify flag in desktop
files, and then later once it becomes common, switch to assumming
notification and have a NoMapNotify for old legacy apps.

Regards,
                                        Owen