Yes those branches are not related at all. Unless we expect each client to create a fullscreen transparent/empty surface on every output.
Do we really want to support client side decorations? If so we could have a look at xdg-shells way of doing it. When a window drag should be started (because the client clicked on the client side title bar) the client sends a request to move the window according to a given input device. The compositor then either denies or takes over the processing of the input events. I could not verify that, but I assume that the compositor is in charge of ending the window drag. If we expect the client to emit relative surface motion (in surface coordinates - in the surface plane) we need to make sure that unity8 clients receive relative motion. The disadvantage of this would be two or maybe one frame slower than the above. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1420334 Title: [enhancement] Missing client API for relative surface movement Status in Mir: In Progress Status in MirAL: In Progress Status in xorg-server package in Ubuntu: Triaged Bug description: Mir needs a client API to allow surfaces to move themselves relatively. This is required to support full client-side decorations (bug 1398849), and also other apps like Google Chrome and Gnome Nautilus which can be dragged using part of their client areas. To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1420334/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
