[Fwd: Re: Migration of windows between displays]

[Perry Lorier]

Matthias Clasen wrote:
> I sent this to the xdg-list thread, and only just now realized that it
> may well go nowhere currently...

I've CC:'d the list so that my reply will hopefully get archived when 
the list notices and catches up.  I was beginning to wonder where my 
flam^Wdiscussion had gone :)

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

As much as I love text separated by line breaks, it does raise some 
issues, whose line breaks? \n? \r? \n\r? \r\n?

There seems to already be a key/value parser in X applications to parse 
the startup notification data?

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

Cool!  Anyone else got any points to raise over this? or do we have 
consensus on this point?

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

So, to clarify (at least in my mind):

Application A sets _NET_CHANGE_DISPLAY in WM_PROTOCOLS on window Foo to 
say that this window can have it's display changed.

Application B (probably the window manager, but could really be anyone) 
sends a ClientMessage to Application A with the window set to Foo, which 
causes Application A to migrate the window?

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

Indeed.  If authentication data is, in fact to be used, reusing the same 
mechanisms as xauth would mean that this would automagically support 
kerberos, public key, cookies, whatever.

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

Ok, I'm perhaps a bit out of my depth here, what's an "Override 
Redirect"?  A window that isn't managed by the window manager?

Are there uses for Override redirect windows that aren't transient? (ie, 
while you can unmap a a tool tip/pop up menu, other window types might 
be less tolerant?)

Shouldn't this be up to the application when it moves a window, it 
should move associated override redirect windows?  Is there likely to be 
a legitimate reason to migrate an override redirect window without some 
kind of parent window?

My quick google suggests that override redirect windows can be 
"InputOnly" which sounds like the kind of thing that listens for global 
key presses (eg for multimedia keys), and probably has lots of other 
uses.  Is this kind of thing likely to make sense to migrate?  Should we 
prohibit it's migration?  The application can of course just refuse  to 
allow that window be migrated (by not announcing the migration option in 
WM_PROTOCOLS)

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

Exactly, and if you're migrating windows away from a desktop onto a null 
desktop in preparation for a user to logout, you may want to cancel the 
logout if the application cannot be migrated.

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

It provides useful feed back to the user.  "You do not have permission 
to migrate this application onto Projector:0" vs "Projector:0 could not 
be found or does not exist, please try again" vs "Projector:0 does not 
appear to be running a display to migrate this application to" vs 
"Unable to migrate this window to Projector:0"

Other actions could perhaps be taken if the display was unable to be 
connected to, perhaps fall back to some other display, or create another 
one to move them to.

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

Sounds reasonable to me.

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

I still contend that this perhaps isn't as obvious to the user, or what 
it should do.  This can be easily done on an application basis if need 
be by not setting the ->window field of the ClientMessage structure. 
However, as you mention, this can certainly be added later.  Simple is best.