Merge lp:~alan-griffiths/mir/client-initiates-user-move-and-resize into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Daniel van Vugt on 2017-03-30 |
| Approved revision: | 4116 |
| Merged at revision: | 4129 |
| Proposed branch: | lp:~alan-griffiths/mir/client-initiates-user-move-and-resize |
| Merge into: | lp:mir |
| Prerequisite: | lp:~alan-griffiths/mir/request-with-authority |
| Diff against target: |
385 lines (+293/-0) 9 files modified
include/client/mir_toolkit/mir_window.h (+9/-0) src/client/mir_surface.cpp (+5/-0) src/client/mir_surface.h (+1/-0) src/client/mir_surface_api.cpp (+14/-0) src/client/symbols.map (+2/-0) src/protobuf/mir_protobuf.proto (+1/-0) tests/acceptance-tests/CMakeLists.txt (+1/-0) tests/acceptance-tests/client_mediated_user_gestures.cpp (+259/-0) tests/acceptance-tests/drag_and_drop.cpp (+1/-0) |
| To merge this branch: | bzr merge lp:~alan-griffiths/mir/client-initiates-user-move-and-resize |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Mir CI Bot | continuous-integration | Approve on 2017-03-29 | |
| Gerry Boland | Abstain on 2017-03-28 | ||
| Daniel van Vugt | 2017-03-24 | Abstain on 2017-03-28 | |
| Chris Halse Rogers | Approve on 2017-03-27 | ||
| Andreas Pokorny (community) | Approve on 2017-03-27 | ||
|
Review via email:
|
|||
Commit Message
Client side and initial tests for a client initiating a user move gesture
| Daniel van Vugt (vanvugt) wrote : | # |
I've linked the 'move' bug 1420334.
But why write more code for client-initiated resizing? That already works :)
| Daniel van Vugt (vanvugt) wrote : | # |
As an example of a self-resizing client, try 'tiled' which has a resize grip in the bottom right corner. It already works.
| Alan Griffiths (alan-griffiths) wrote : | # |
> I've linked the 'move' bug 1420334.
>
> But why write more code for client-initiated resizing? That already works :)
No it doesn't. ;)
I agree clients can resize, but they can't request the shell to initiate a resize gesture. There is no way to invoke the touch resize handles under U8, drag the left edge or top.
| Daniel van Vugt (vanvugt) wrote : | # |
That's true, but the feature you're talking about in Unity7 also does not have resize handles (right click titlebar and then Resize, or just Alt+F8).
So either the client initiates the resize, and that works perfectly already; or
the server initiates resize, and that works perfectly already too.
Even if you did want it to pop up the resize handles, that's still a shell operation since the window menu itself is part of the shell. Not part of the client.
I think this branch should be just about movement.
| Andreas Pokorny (andreas-pokorny) wrote : | # |
There is a difference between submitting a buffer with a different size, and resizing a window. So if we want to support CSD, this change is necessary.
| Gerry Boland (gerboland) wrote : | # |
How is this API to be used by the client? I.e. where is the client specifying the new size/position?
Is it that the client gets a mouseDown event with a cookie that it decides should cause a resize/move, so calls the mir_window_
(a) shell intercepts all other input events, instead sending resize events to the client? Or
(b) shell keep sending the mouseMove events to the client, and client resizes its window/buffer as it pleases (WM can restrict those choices though)?
On resize completion, mouseUp event finally sent to client?
If a user wants to resize the top-left corner of a window, is that a move & resize? Should that be an atomic operation instead?
The only reason I see that Mir's current window resize api is insufficient for client-
| Alan Griffiths (alan-griffiths) wrote : | # |
> How is this API to be used by the client? I.e. where is the client specifying
> the new size/position?
The client isn't specifying the position or size. It is requesting the shell treats an input event as the beginning of a gesture.
> Is it that the client gets a mouseDown event with a cookie that it decides
> should cause a resize/move, so calls the mir_window_
> that cookie. Then
> (a) shell intercepts all other input events, instead sending resize events to
> the client? Or
> (b) shell keep sending the mouseMove events to the client, and client resizes
> its window/buffer as it pleases (WM can restrict those choices though)?
> On resize completion, mouseUp event finally sent to client?
(a)
> If a user wants to resize the top-left corner of a window, is that a move &
> resize? Should that be an atomic operation instead?
That's an atomic operation in those shells that currently support it. Initiating the resize through a client API shouldn't change that.
> The only reason I see that Mir's current window resize api is insufficient for
> client-
> shell-themed resize image, and to remain that image even if the cursor moves
> beyond the window borders.
Hmm, I can see it will be easier to reach consensus on the USER_MOVE codepath. Maybe I should split that out?
| William Hua (attente) wrote : | # |
Andreas is right, even if we can change the buffer size, this isn't the same as requesting a resize operation from an input event.
In gtk, we have this api we're expected to implement:
https:/
So for mir_window_
I wouldn't expect the client to get a mouse up event on completion of the resize, or any events other than resize ones during the client's resizing. So from Gerry's comment, (a) is the most sensible for us in gtk, especially from the api's point of view. If there's non-resizable windows, the server should already know that from the time the window was created, and just reject any resize operation in that case.
It also needs to be implemented so that the user can also resize using the keyboard arrow keys as well.
| Alan Griffiths (alan-griffiths) wrote : | # |
> Hmm, I can see it will be easier to reach consensus on the USER_MOVE codepath.
> Maybe I should split that out?
OK, I'm dropping the resize code from this MP as it clearly needs further consideration.
| Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:4115
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
| Daniel van Vugt (vanvugt) wrote : | # |
*shrug*
My request has been satisfied but I would hazard a guess this functionality may take us a few attempts to cover all the major use cases.
| Daniel van Vugt (vanvugt) wrote : | # |
I'm fairly sure we need zero more work done on resizing. All the resizing use cases are covered by existing APIs.
On the topic of client-initiated movement though, please start thinking about the Chrome/Chromium use case too: You drag a tab out of the window, that then creates a new window where the cursor remains on the same relative tab coordinate in the new window. If it's not baked in to the drag action then we'll need to be able to create that new top-level window at a precise coordinate relative to the old window (which may be the parent but can also be closed leaving just the child open).
| Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
https:/
Executed test runs:
FAILURE: https:/
None: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
| Daniel van Vugt (vanvugt) wrote : | # |
04:02:04 Text conflict in src/client/
04:02:04 1 conflicts encountered.
- 4116. By Alan Griffiths on 2017-03-29
-
merge --weave :parent
| Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:4116
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/

PASSED: Continuous integration, rev:4112 /mir-jenkins. ubuntu. com/job/ mir-ci/ 3238/ /mir-jenkins. ubuntu. com/job/ build-mir/ 4358 /mir-jenkins. ubuntu. com/job/ build-0- fetch/4445 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= vivid+overlay/ 4435 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= xenial+ overlay/ 4435 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= zesty/4435 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= clang,platform= mesa,release= zesty/4390 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= clang,platform= mesa,release= zesty/4390/ artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= xenial+ overlay/ 4390 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= xenial+ overlay/ 4390/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= zesty/4390 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= zesty/4390/ artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= cross-armhf, compiler= gcc,platform= android, release= vivid+overlay/ 4390 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= cross-armhf, compiler= gcc,platform= android, release= vivid+overlay/ 4390/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= android, release= vivid+overlay/ 4390 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= android, release= vivid+overlay/ 4390/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= mesa,release= xenial+ overlay/ 4390 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= mesa,release= xenial+ overlay/ 4390/artifact/ output/ *zip*/output. zip
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild: /mir-jenkins. ubuntu. com/job/ mir-ci/ 3238/rebuild
https:/