Migration of windows between displays

[Matthias Clasen]

On Wed, 2004-12-01 at 10:23 +0000, Matthew Allum wrote:
> Hi;
> 
> 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 ?
> 

Yes.

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

Yes thats what I meant. One could also specify the property as a list of
strings, first string being the displayname, and each further string
being a key-value pair. That would completely avoid the need for parsing
in the simple case of no key-value pairs, since Xlib offers functions to
obtain the property value broken into individual strings.

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

I think it is mainly a quality of implementation question for the
"mover" that it doesn't lock up if the moved application doesn't return
status feedback. Using a timeout should be good enough to ensure that.
Maybe that should be mentioned in the spec.

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

Yes, my implementation does that. Not sure if it needs to be part of the
migration protocol itself. We also have to think about cases like moving
a window which already has the property, what should happen in that
case ? 

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

"mirroring" as in showing on both displays ? 


Matthias