Re: screen/display switching

[Owen Taylor <otaylor redhat com>]

(I'm leaving xdg-list CC'ed here, because it isn't clear
 to me whether this is an inter-app or a WM-app issue.)

Comments on _NET_SCREEN_CHANGE

 - The use of the startup-notification string-of-client messages
   transport bothers me a bit (startup-notification doesn't
   actually require toolkits/applications to participate in
   the protocol in most cases.)

   It's most needed for startup-notification because it's very
   hard to do broadcast messages in a race-condition free
   manner without it. But here we don't need broadcast, so
   the protocol could just be to put a property on the 
   application window, and for the application to delete the
   property when it has retrieved the information.

   (The property atom would be passed in the client message)

 - The data transported should be extensible. E.g., if
   we go with string-of-client-messages, the data should
   be in key-value-form rather than just a single piece  
   of data. If we use a property on the application window,
   that should be done in an extensible way.

 - The WM_PROTOCOLS atom should be the same as the 
   message type to avoid having to intern unnecessary
   amounts of atoms. (Interning an atom is round-trip
   to the server unless you take special precautions)

 - :1 should definitely not refer to "screen 1 of the
   current display", since X typically treats this as 
   the same as :1.0. I think passing the display name
   and target screen as separate optional entities
   would make sense.

 - I don't sending to the group leader to move the
   entire app works, since there is no guarantee
   that the group leader is unique from one of the
   application's windows. Move window vs. 
   Move application probably needs to be a separate
   piece of data in the protocol.

   GTK+ automatically moves transients along with
   the main window ... for this, you'd want the
   reverse to hold as well. That should presumably
   be specified in the protocol, to avoid WM's
   trying to move the transients themselves one
   by one.

 - Never hurts to include a timestamp (for the current
   server/display)

Comments on _GPE_DISPLAY_CHANGE:

 - Doing things via WM_PROTOCOLS like _NET_SCREEN_CHANGE
   I think is better than a magic property that
   both parties change.

 - A migrated window isn't going to keep it's
   properties, so "reset _GPE_DISPLAY_CHANGE property
   to zero length" doesn't make sense to me. Then
   again, I don't see any reason to need to protect
   against migrating a newly-migrated window. It
   should just work.

 - Status back to the mover would be a nice touch, 
   but is going to make things considerably more
   complex. I think  we should just give the migrated
   app the option of putting up an error message
   on failure if it so chooses.

 - Why does authentication need to be in the protocol?
   If we want to deal with mixed trusted and non-trusted
   applications on a trusted display, you need Xsecurity
   and to restrict the flow of data between applications.

   I don't think we should even consider the case of
   applications on a hostile display ... Xlib hasn't
   gotten a lot of work in this area, toolkits would
   need extensive auditing, and some "exploits" 
   (password entry) are not even exploits. If you
   wanted to go down this route, I'd think about putting
   an audited, trusted proxy X server in the middle
   to simplify the equation. (You might want protocol-
   specific proxies for things like Xdnd, or simply
   forbid all IPC between different user's applications)

Regards,
                                    Owen