Re: launch feedback status update

[Havoc Pennington <hp redhat com>]

Mark McLoughlin <mark skynet ie> writes: 
> 	o I'm concerned that this is totally oriented around a flag in the
> 	  .desktop files. How about launchs that currently don't involve
> 	  a .desktop file e.g. from the run dialog, hardcoded binary names,
> 	  launching a uri handler ? With the run dialog, we already match
> 	  against .desktop files where we can so maybe thats okay. Where
> 	  binary names are hardcoded maybe we can hardcode the .desktop
> 	  uri instead or even just hardcode whether the binary supports
> 	  feedback (or its legacy name).

Well the spec doesn't require .desktop files - any reliable mechanism
of finding out if an app being launched supports feedback is
allowed. e.g. we could just have a global list of binaries or something.

I don't see a way around requiring some kind of mechanism, unless we
want a lot of stuck busy cursors.

> 	o Any real need for the LAUNCHEE part of the uniqueness
>  string? 

It's just random debugging info. There's no real need to specify what
the string is at all probably.
 
> 	o Its sometimes confusing in the text the difference between
> 	  launcher/launcher program/launchee/launch manager/feedback program
> 	  etc. I'd suggest sticking with launcher/launchee and launch
> 	manager.

I sort of excised the launch manager since people seemed to find it
intimidating; but it's likely I should put it back.

> 	o _NET_LAUNCH_DESKTOP: how does the WM know the launch sequence window
> 	  in order to read this. Does this force the spec to be implemented in
> 	  the window manager ? Or do you expect the WM to monitor
> 	  _NET_LAUNCH_INITIATE messages for this too?

Yes, I expect the WM to be aware of the spec and pick up
_NET_LAUNCH_INITIATE. See the LfMonitorContext object in my little
library.

> 	o _NET_LAUNCH_ICON_NAME: would a _NET_LAUNCH_ICON not be useful to
> 	  the tasklist ?

You mean the actual icon data? Perhaps so.

> 	o You might want to add "Sets _NET_LAUNCH_COMPLETE", "Handles
> 	  _NET_LAUNCH_COMPLETE by destroying launch sequence window" to the
> 	  launcher responsibilities.

Yes.

> 	o You should also add "Sets _NET_LAUNCH_COMPLETE", "Compares legacy
> 	  class/name/title on newly mapped windows", "Handles
> 	  _NET_LAUNCH_COMPLETE by stopping feedback" to the launch manager
> 	  responsibilities. Oh hold on, you have a FIXME on who should set
> 	  _NET_LAUNCH_COMPLETE  for legacy apps ... who else would do the
> 	  matching ?

Good question. ;-)

> 
> 	o The .desktop legacy keys are confusing when compared with the launch
> 	  sequence window property names e.g.
> 		LaunchLegacyTitle <-> _NET_LAUNCH_LEGACY_NAME
> 		LaunchLegacyName  <-> _NET_LAUNCH_LEGACY_RESOURCE_NAME
> 
> 	  Maybe use LaunchLegacyResourceName, LaunchLegacyResourceClass and
> 	  LaunchLegacyName?

Good point.

> 	o Requiring the launchee to send _NET_LAUNCH_INITIATE to all root
> 	  windows seems a little funny to me.
> 
> 	  What about an app that is only opening a new document window?  Why
> 	  should it have to be multiscreen aware? Why not just require the
> 	  message to be sent to the root window on the same screen on which the
> 	  launch sequence window is realised ?

You are probably right - we could instead suggest that the launch
feedback apps such as task list _watch_ all screens.

> 	  It seems better to require the launch manager to be multiscreen
> 	  aware rather than every app.

Right.

> 	o The toolkit could actually take advantage of the DESKTOP_LAUNCH_WINDOW
> 	  environmental variable by setting the default screen for the launchee
> 	  to be the same screen as the one the launch sequence window is
> 	  realised. Bit of a kludge but ...

Well, we _could_ just set DISPLAY when launching apps ;-)

> 	o What happens if launcher wants to launch a launchee on a different
> 	  display? The launcher would have to open the other display? Are there
> 	  any problems with this? Don't think so ...

It seems reasonable to require that.

> 	o A launchee should be recommended to always clear
> 	  $DESKTOP_LAUNCH_WINDOW and $DESKTOP_LAUNCH_ID once its read them. It
> 	  seems easier to do this than requiring its done only when launching
> 	  another launchee before ending the launch sequence.

Yep.

> 	* I assume we'll have a longer timeout for legacy apps since they can't
> 	  do the pulse thing ? Will only the first mapped window with that
> 	  class/name/title will be associated with that launch sequence? If
> 	  there are two launch sequences that match that class/name/title you
> 	  end the first (as determined by the timestamps in
> 	  _NET_CLIENT_INITIATE) launch sequence right ?

I'm not sure long timeouts are a good idea (it increases the breakage
if you fail to end feedback). But definitely something easy to tune
according to experience.

Havoc