Migration of windows between displays

[Matthias Clasen]

I sent a response to this thread, but it seems to have gone to /dev/null
while fd.o was down, and I lost my original mail, so here is a quick
summary of what I tried to say...

I have looked at Perry Lorniers and Philip Blundell proposals for a 
"intiate display change" protocol, and worked on implementing it 
in GTK+. Below is a quick description of what I have implemented,
and would like to propose.

Matthias



Migration protocol
------------------

0. Terminology

We have an "old display" and a "new display". "window" is the w
indow that is being moved from the old display to the new display, 
"mover" is the app that initiates the move. It must have a connection 
on the old display in order to send messages to the window, but it 
may in fact be an application which whose "home" is the new display 
(pull scenario)


1. Declaring participation in the protocol

If the client who owns the window wants to allow moving it to a 
different display, it puts the _NET_CHANGE_DISPLAY atom in the 
WM_PROTOCOLS property on window. The idea here is that windows which 
don't support _NET_CHANGE_PROTOCOLS would not be listed when displaying 
a list of move candidates. Note that clients must still be prepared to 
get _NET_CHANGE_DISPLAY messages even if they don't list the protocol.


2. Initiating the move

Mover puts a property on the window, containing the name of the display 
to move to, optionally followed by key-value pairs separated by line 
breaks.
  
The display name must be a hostname:display.screen display name as 
understood by XOpenDisplay(). It is important to realize that the 
hostname must be suitable for connecting to the new display from 
wherever the client owning the window runs. E.g if the mover is 
actually running on the new display, the string returned by 
XDisplayName() is most likely *not* suitable, since it may contain 
"localhost" or the empty string as hostname. 

The atom naming the property can be freely choosen by the mover (a good 
choice would be _NET_CHANGE_DISPLAY)

The mover sends a WM_PROTOCOLS client message as specified in the ICCCM 
to the window with the following:

  format:  32
  type:    WM_PROTOCOLS
  data[0]: _NEW_CHANGE_DISPLAY
  data[1]: <timestamp>
  data[2]: <property-name>
  data[3]: <status-window>

where status-window is the X id of a window on which the mover listens 
for the client message indicating that the move is done. If this is set 
to None, the client message is sent back to the root window of the old 
display.


3. Moving

When the client owning the window receives the aforementioned message, 
it connects to the new display, recreates the window and all transients 
belonging to it over there and closes the window on the old display.

It then sends a client message on the old display to the status window 
specified in the message with the following contents:

  format:  32
  type:    _NET_CHANGE_DISPLAY
  data[0]: <window>
  data[1]: <status>
  data[2]: <new-window> 

where window is the id of the window on the old display,

the status code is interpreted as follows
  0       success
  1       unable to connect to display
  2       requested screen does not exist
  3       invalid authentication (not currently used)
  4       indeterminate failure
  5       move refused by the client who owns the window
	
and new-window is either the id of the moved window on the new display, 
or None if the move was not successful or if the window id is not 
available for some other reason.