[enhancement] Missing client API for relative surface movement (e.g. dragging client-decorated windows)

Bug #1420334 reported by William Hua on 2015-02-10
42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Medium
Alan Griffiths
MirAL
Medium
Alan Griffiths
mir (Ubuntu)
Undecided
Unassigned
xorg-server (Ubuntu)
Wishlist
Unassigned

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

Related branches

Daniel van Vugt (vanvugt) wrote :

We can do all this on the server side already so I assume you mean missing client API calls?

For the client API:

resizing: Missing, yes I know
moving: Missing, yes I know clients need to be able to do relative movements of themselves (e.g. fully client decorated).
restacking: Not sure this is a client thing... Localized stacking order is implied by parenthood between surfaces. And changed thereafter entirely by the shell.

But the first 2 out of 3 are definitely missing features. We should break them up into separate enhancement requests.

OK, separated...

movement: This bug
resizing: Bug 1420573

summary: - Missing API for surface movement, resize, bring-to-front
+ [enhancement] Missing client API for relative surface movement
description: updated
Changed in mir:
importance: Undecided → Medium
status: New → Triaged
tags: removed: resize
tags: added: clientapi
Changed in xmir:
status: New → Confirmed
importance: Undecided → Wishlist
Daniel van Vugt (vanvugt) wrote :

I've now proposed a common solution for this and other scenarios at the top of bug 1420573.

tags: added: make-xmir-default
tags: added: xmir
tags: removed: make-xmir-default
affects: xmir → xorg-server (Ubuntu)
Robert Ancell (robert-ancell) wrote :

It might also be desirable to mark surfaces as tracking the cursor instead of having each client convert the pointer motion events into surface move events.

description: updated
Daniel van Vugt (vanvugt) wrote :

I suspect that would not be as portable a solution to other platforms for the affected apps like Chrome and Nautilus.

Either way, a bug should usually try to focus on the problem definition and less on describing possible solutions.

tags: added: enhancement
Alan Griffiths (alan-griffiths) wrote :

How much of this need is addressed by mir_surface_spec_set_streams() et alia?

Changed in xorg-server (Ubuntu):
status: Confirmed → Triaged
Changed in mir:
assignee: nobody → Alan Griffiths (alan-griffiths)
status: Triaged → In Progress
Changed in mir:
milestone: none → 0.25.0
Changed in miral:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Alan Griffiths (alan-griffiths)
Daniel van Vugt (vanvugt) wrote :

The branch that just landed doesn't resolve this I think. We're still lacking a simple move {dx,dy}

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.

William Hua (attente) wrote :

> Do we really want to support client side decorations?

Just to comment on this one point, I think CSD is just something we must support and there's no way around it. There are already a lot of GNOME apps rendering widgets in the header bar in a way that just simply can't be done with SSD. Add to that applications like Google Chrome and Steam which want full control over their rendering and still allow the user to move their windows by dragging on the client area.

Daniel van Vugt (vanvugt) wrote :

Please try to keep the discussion about client-side decorations in bug 1398849. That enhancement is certainly open and has not been rejected so don't worry.

Chris Halse Rogers (raof) wrote :

I'm +1 for Andreas' mir_surface_start_window_drag(MirEvent const* initiator), -1 letting a client arbitrarily move their surfaces around.

This will be easier for GTK and Qt than mir_surface_move(), as this is the behaviour already implemented by xdg-shell.

I think the right way forward is to allow the client to request drag (similar to the existing mir_surface_raise() request).

William, can you confirm this could work for you?

Changed in mir:
status: In Progress → Incomplete
Changed in miral:
status: In Progress → Incomplete
Daniel van Vugt (vanvugt) wrote :

We/I need to check Xmir and see what kind of API it needs too.

Changed in mir:
milestone: 0.25.0 → 0.26.0
Changed in mir:
milestone: 0.26.0 → 1.0.0
summary: - [enhancement] Missing client API for relative surface movement
+ [enhancement] Missing client API for relative surface movement (e.g.
+ dragging client-decorated windows)
description: updated
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mir:
status: Incomplete → In Progress
Mir CI Bot (mir-ci-bot) wrote :

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.27.0

Changed in mir:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :
Download full text (8.3 KiB)

This bug was fixed in the package mir - 0.27.0+17.10.20170630-0ubuntu1

---------------
mir (0.27.0+17.10.20170630-0ubuntu1) artful; urgency=medium

  [ Daniel van Vugt ]
  * New upstream release 0.27.0 (https://launchpad.net/mir/+milestone/0.27.0)
    - ABI summary:
      . mirclient ABI unchanged at 9
      . mirserver ABI bumped to 44
      . mircommon ABI unchanged at 7
      . mirplatform ABI bumped to 61
      . mirprotobuf ABI unchanged at 3
      . mirplatformgraphics ABI bumped to 13
      . mirclientplatform ABI unchanged at 5
      . mirinputplatform ABI bumped to 7
      . mircore ABI unchanged at 1
    - Enhancements:
      . Mostly groundwork required to support major enhancements coming in
        future Mir versions.
      . Removed android-input and eliminated the entire "3rd_party/" subtree.
        Now the Mir source tree contains original code only.
      . Added mir_prompt_session_new_fds_for_prompt_providers_sync API.
      . mirout: Added load and save options for keeping display configs
        on disk.
      . mirout: Added "--" support for applying configuration changes under
        Unity8.
      . Fixed failure of DRM hardware cursor {hide(); show(image);}
      . Added server option: "--cursor software" (MIR_SERVER_CURSOR=software)
      . Added letterboxing/black bars support to the GL renderer in preparation
        for generic output cloning.
      . Added client API for getting the logical size of an output.
      . Migrated MirCookie to use SHA-256.
      . Ensure RealKMSOutputConfiguration stays in sync with actual hardware
        state.
      . Added support for drag-and-drop.
      . Lots of other client API enhancements.
      . Minor clean-ups, optimizations and dead code removal.
      . Added support for building on Ubuntu 17.10 artful.
      . Update example code to use undeprecated API.
      . mesa-kms: Support hardware cursors in hybrid setups.
      . Rework and publish the graphics platform APIs
    - Bugs fixed:
      . [enhancement] Make able to get version information from client /
        server APIs (LP: #1195540)
      . Touch screen coordinates don't rotate with the screen (LP: #1349660)
      . Subpixel order not included in Mir display information (LP: #1393578)
      . [enhancement] Missing client API for relative surface movement (e.g.
        dragging client-decorated windows) (LP: #1420334) . Mir does not reset
        key states when paused or resumed (modifiers get stuck after VT
        switching) (LP: #1536279)
      . NBS never uses mc::MultiMonitorMode::single_monitor_fast, even when
        only a single monitor is plugged in (LP: #1561418)
      . Inconsistent behaviour of Num Lock (LP: #1588237)
      . A scaled (not panned or clipped) mirror/clone mode is desired
        (LP: #1639226)
      . Rotating an output left or right without restarting the
        compositor distorts the image (LP: #1643488)
      . support display scaling slider in unity8 (LP: #1645372)
      . [ FAILED ] NestedInputWithMouse.mouse_pointer_coordinates_in_nested_
        server_are_accumulated (LP: #1646375)
      . [ FAILED ] NestedInputWithMouse.mouse_pointer_position_is_in_sync_with_
        ho...

Read more...

Changed in mir (Ubuntu):
status: New → Fix Released
Changed in mir:
status: Fix Committed → Fix Released
Changed in miral:
status: Incomplete → In Progress
milestone: none → 1.5
Changed in miral:
milestone: 1.5 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers