Re: Application launch detection

[Peter Astrand <astrand lysator liu se>]

Hello to all. I'm sorry that I couldn't reply earlier, but I have been
quite busy (partly because I have been given an GNOME speak tonight :-)

(This is a long mail...)


On 11 Nov 2000, Owen Taylor wrote:

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

Yes, and the main part (in my experience) of the start time is to load the
binary from disk/network. When the application has started communicating
with X, it's more or less "started". 

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

Ok, true. Do you mean that this can and should be solved by the approach:

1) Setting some window property
2) Check when the actual toplevel window is mapped

Or do you have other suggestions for a better implementation?

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

But if XMapWindow() is doing exactly what it should, according to all
man-pages, specifications etc, why should things break? And why is Xlib so
special: If we want to add some feedback-hook into GTK, won't applications
break then, because some "depends on it [the GTK function] 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.

Ok. I'm not X11 expert. I believe you...

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

Ok, you are right. 

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

Netscape is not an normal-sized application :)

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

I'm not convinced on this one. The whole idea behind layering is that you
should be able to change lower levels, and apps shouldn't notice. If it
*was* possible to change some library (for example Xlib) without negative
consequences, this be the right thing to do, IMHO. 

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

It depens on what you mean by quickly... This app start feedback thing is
quite small - probably, many developers will think it's
unnecessary/unimportant. 

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

Yes, it's and alternative. If we really can't find an better approach, I
agree on this one. 

Another alternative is to ignore the application identification problem
altogether, and only check for map events. Maybe this could be used for
example when you do "Run..." and type in an X app. 



On 11 Nov 2000, Havoc Pennington wrote:

> Therefore we need to plan on requiring toolkit support. We can do an
> LD_PRELOAD hack on some platforms for some apps, but this sure
> shouldn't be the default case or the long-term solution.

Agree, LD_PRELOAD sucks. 

> Peter, could you write down a more formal description of how the
> XSendEvent() works, so we can get a spec that explains that mechanism?
> We need to document exactly what toolkits should do (what properties
> to set, events to listen for, name of the env variable to use).  Then
> GTK and Qt can implement it, and maybe we can even get Xt/Motif to do
> so.

I haven't understood how a toolkit-based implementation would work. (Sorry
if you have already has explained it, I may have missed some mails). Is
the idea to add some code to gtk_init() or similiar? This would suffer
from the same problem as Owen mentioned above: Apps can do gtk_init() and
then wait forever before actually showing the windows. 

I'll look into this when time permits. 

> Also, are you interested in working with George on this issue for
> GNOME 1.4 - I guess modifying Xalf so the panel and Nautilus can use

Yes, I'm interested (but as always, I'm not sure about how much time I can
spend on this). I also think Mary Dwyer can help us. 


-- 
/Peter Astrand <astrand lysator liu se>