Another interesting case is how to handle tabs being dragged out of Chrome/Chromium. In such a case the window being dragged does not exist for the start of the gesture; it only appears during the drag. Furthermore, the cursor coordinate in the newly created drag window is on the tab itself and not the titlebar.
We have the benefit of knowing that drag gestures in Mir continue to send events to the window where they started until a button is released. So it seems the answer is that this is a matter of the parent window just creating and moving a child. It's not a shell operation but an application operation to move such a window. -- 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 (e.g. dragging client-decorated windows) Status in Mir: Incomplete Status in MirAL: Incomplete 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. Later additions that are so similar I think they are part of the same bug: there need to be client APIs for "always on top" and "client initiate resize". 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
