Migration of windows between displays

[Matthias Clasen]

On Wed, 2004-11-10 at 04:50, Perry Lorier wrote:
> 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.

I'd rather see them separated by line breaks.

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

I think I agree with this. Using a single DISPLAY key where the value
is a classical host:display.screen X display name seems good enough.
We can let the initiator of the move worry about constructing display
names for specific screens.

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

Owen proposed the most elegant approach, IMO: put a property on the
app window holding the details, then send a ClientMessage with type
_NET_CHANGE_DISPLAY containing the atom identifying the property
(the atom could be _NET_CHANGE_DISPLAY again, but that isn't required).
This is also how WM_PROTOCOLS is defined to work by the ICCCM (wm sends
client message using the atom put in WM_PROTOCOLS to initiate the
action)
It has the additional advantage that you don't have to worry about
cleaning the _NET_CHANGE_DISPLAY property.

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

I agree with this. using a key-value syntax in the property holding
the display name would allow to add authentication data if people think
it is necessary.

> 
> * Transients associated with the window should be moved too.
> 

Yes. Override-redirects like menus or tooltips associated with the
moving window should probably just be unmapped before moving. 

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

In terms of error handling, I think for a good user interface we need
to send some error notification back to the mover. Letting the toolkit
pop up an error dialog is not going to help, since it is going to appear
on the old display, whereas we want it (at least in "pull" scenarios)
to appear on the new display. 

I like the GPE approach of sending a clientmessage indication the
outcome of the move, with the following data:

l[0]	window handle for which status is being reported
l[1]	status code, one of:

0	success
1	unable to connect to display
2	requested screen does not exist
3	invalid authentication
4	indeterminate failure

Although I don't think that discriminating between 1, 2 and 3 is very
important. I don't particularly like sending the ClientMessage back to the 
root window (the root window is a bit like a crowded chat room where all
apps have to ignore most of what is said to find the one message meant for
them), but that could be avoided, e.g by having the mover identify a
window to send the status message back to in the property, via a line

STATUS_WINDOW=<window-id>
 
which would default to the root window if not specified.

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

I would like to see some provision for moving groups of windows or a
complete application, but that can certainly be added later.

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

display name

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

_NET_CHANGE_DISPLAY is more like an command, whereas 
_NET_DISPLAY_CHANGE sounds more object-oriented, as if you were
calling a change method on a display object. I think the command
fits better here.


Matthias