Migration of windows between displays

Matthew Allum mallum at gmail.com
Wed Dec 1 12:23:13 EET 2004


Looks good to me, Some quick comments/questions ;

> 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 

                           ^^^^ This should be _NET_CHANGE_DISPLAY ?

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

There is a line break after the display name ? key-values are in the
format 'key=value' .desktop style ?

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

There is a possible issue where the migrating app locks up or crashes
during the migration and therefore never manages to send its status.
Im not sure if there is a nice way to detect this, maybe a combination
of a timeout and _NET_WM_PING usage ? Maybe the above should be more
specific in noting the window should only be closed on the old display
*after* the window on the new display has been successfully created ?
That would also make this issue easier to detect.

Would it be useful to have a property on migrated windows indicating there 
originating display ? This would be useful for 'returning' windows. 

Would _NET_USE_DISPLAY be better naming ? Im just thinking about the
case of *mirroring* apps on another display which the above could be
used for ( via setting some key=value ).

Many thanks;

  -- Matthew Allum

More information about the xdg mailing list