Re: Application launch detection

[Havoc Pennington <hp redhat com>]

Hi,

Thanks for copying Mary, I was just kicking myself for forgetting to
do that. Mary there are list archives at
mail.gnome.org/archives/wm-spec-list with the whole thread.

Peter Astrand <astrand lysator liu se> writes: 
> Actually, the current version doesn't advertise atoms on the mapped
> windows. Instead it signals the "tracking process" with a simple
> kill(pid, SIGUSR1). If we wan't a more centralized approach, the kill can
> be replaced by an XSendEvent, which sends an signal to the root window. An
> central "feedback server" can listen for these types of events. 
>

I think the kill(pid, SIGUSR1) is quite evil; apps may use USR1 for
something else. We shouldn't appropriate USR1 for what's essentially a
system function since it's reserved for apps.

The XSendEvent solution sounds like it could be a good plan. The
advantage would be that the launcher app avoids monitoring all mapped
windows, right? This still uses an env variable, just doesn't set a
property on client windows, correct?
 
> This must be done by the toolkit. Even if both GTK and QT supports this,
> there is still lots of applications not supporting this. Maybe we have to
> live with that, but it would be great if we could do better than this. 
> 

I think we should:

 a) Come up with a reliable working solution that toolkits can implement
 b) Figure out how to hack something up for legacy apps

as two separate steps. If we don't specify a 100%-reliable solution
for new "desktop aware" apps we'll never reach 100% reliability. If we
do specify it, legacy apps will get fixed or go away eventually, and
can be hacked around in the meantime.

If a) and b) use the same mechanism, that's simpler, but it's not
required.

Havoc