[Fwd: Re: Migration of windows between displays]

[Matthias Clasen]

On Thu, 2004-11-18 at 06:28, Perry Lorier wrote:
> 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?

An even simpler solution would be to store a string list in the
property. No real need to parse here. 

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

In trying to implement my proposal I learned that you still need to
parse the display name. The reason is that XOpenDisplay will always give
you a new connection, which is not really what you want when you are
asked to e.g. move from :0.0 to :0.1 . I'm comparing the display name 
with the names of already open displays, ignoring the screen part.
> 
> >>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?

Yes, B sends a client message to Foo, which causes A to migrate Foo.
Before sending the message B stores the details of where to migrate to 
in a property on Foo, and includes the name (ie the atom) of the
property in the message.


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

Yes, override redirect windows are those that aren't managed by the wm,
typically menus and tooltips. They are not normally marked as transient
for some other window, since that information is only useful to the wm
(which isn't involved in this case at all).

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

I think it is fine to leave reasonable handling of override redirect
windows to the application, I just figured that if the spec includes a
paragraph clarifying the handling of transients, it may be good to at
least mention how override-redirect windows might be handled.

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

In implementing my proposal, I found that it is more elegant to put the
id of the status window in the initial client message instead of this
property, and go back to the format where the property contains just the
display name, optionally followed by key-value pairs. Done in that way,
we avoid the need to parse the property for key-value pairs unless we
actually need it.

Matthias