Re: launch feedback status update



Hey Havoc,
	The propsal looks great - very well thought out. I'm
particularily pleased with the simple legacy apps support, the
incorporating of the desktop number into the launch properties and
fact that this can be used for opening new windows in an app.

	Anyway, some thoughts:

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

	o Any real need for the LAUNCHEE part of the uniqueness string?  It
	  seems an unneccessary burden for the launcher to have to figure out
	  what the launchee's name is (e.g. parsing a command line string) ...
	  It seems the UNIQUENESS part achieves the same effect. Why not make it
	  enforce the use of pid/hostname to uniquely identify the launcher? Or
	  how about recommending the use of a toplevel xid from the launcher to
	  uniquely identify an instance of the launcher?

	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.

	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?

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

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

	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 ?

	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?

	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 ?

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

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

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

	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.

	* 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 ?

Good Luck,
Mark.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]