Migration of windows between displays

[Perry Lorier]

Havoc Pennington wrote:
>>The bugzilla entry is available here: 
>>http://bugzilla.gnome.org/show_bug.cgi?id=153351
>>
>>What are peoples comments on this idea?
> 
> There's been some previous hacking on it, though I don't think anyone
> finished; see for example this thread:
> http://mail.gnome.org/archives/wm-spec-list/2003-March/msg00018.html
> 
> Google or bugzilla search may turn up some more history.

I've not found any other discussion in bugzilla or google despite a long 
search.

Encouragingly the wm-spec discussion you linked to above basically did 
exactly what I did.  The specification as presented there covers a few 
more corner cases I did not consider (such as the property not being 
cleared on failure).

Their specification also had a list of key/value pairs, for 
extensibility.  What I implemented only used the raw name of the 
$DISPLAY[1] you wanted the window moved to which I think is conceptually 
simple and easy to follow.  Future expansion can be achieved by adding 
key/value pairs after the display separated by a space if absolutely 
necessary.

The older spec has the display broken apart into key/value pairs which 
(to me) seems excessively complicated and requires complicated parsing 
for no good reason, on the flip side this seems to be inherited from the 
startup-notification spec so presumably applications will already be 
able to parse these. The GPE project use a similar protocol to me, 
however they add an authentication type and key after the display (space 
separated).

The specification you referred to used _NET_SCREEN_CHANGE, which to me 
implies that it's only used for changing between two screens within a 
display, where the protocol should be able to be used for changing 
between displays too.  Hence why I called the atom in my original patch 
  _GTK_CHANGE_DISPLAY.

Matthias Clasen suggests making this a ClientMessage instead of an X 
Property.  I don't really understand the pro's and con's of these two 
approaches.  ClientMessage does sound like a more elegant system, but 
from what I've seen of the X11 protocol, property notification seems to 
be rather prevalent for initiating actions.  Is there any major reason 
to choose one over the other?

Someone suggested adding a timestamp,  I'm not entirely sure why you'd 
want a timestamp on the message?  If it's necessary (or even likely to 
be useful) it could be included after the display separated by a space.

My current thoughts are:
* _NET_DISPLAY_CHANGE is advertised in WM_PROTOCOLS. this is the same 
name as the property used to initiate the action to reduce the number of 
atoms needing to be created avoiding unnecessary round trips to the server.

* Someone sets the property _NET_DISPLAY_CHANGE[2] on a window that 
window then tries to move itself to the destination display immediately.

* The format of the data part of the property is the new $DISPLAY value 
optionally followed by a space and some data which is currently ignored 
(used for future expansion if necessary).

* If the move fails then the property is removed.

* No extra authentication is done, if you have permission to write 
properties to a window then you have permission to migrate the window to 
another display.

* Transients associated with the window should be moved too.

* Error handling is undefined.  Perhaps the sending application can poll 
infrequently to see if the window still exists with a now empty 
_NET_DISPLAY_CHANGE as indication of failure (although no reason can be 
given).  This implies that you should not remove the property from the 
window before removing the window if the change may be successful (as 
this would appear as a failure). Is this prone to race conditions?  Are 
window ID's reused frequently?  Is there a better mechanisms for 
notifying an application of failure without needlessly complicating the 
protocol?

* No provision for moving the entire application other than the 
initiating application doing it's own iterations over everything within 
a class or group, ignoring transients (which are moved as above).  An 
application is an implementation detail that doesn't need to be 
presented to the user (is one application that supports two documents in 
separate windows different from two applications with one document open 
each?)

* There is no _NET_DISPLAY_CHANGE_BEGIN property, I'm not sure why you'd 
want one.

----
[1]: Is there some jargon for the format string that the $DISPLAY 
variable holds?  "display string"?

[2]: People seem to use _NET_DISPLAY_CHANGE rather than 
_NET_CHANGE_DISPLAY like I used in my original patch.  is there any 
convention here I should be aware of?