Merge lp:~alan-griffiths/mir/placement-notification into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Alan Griffiths on 2016-09-15 |
| Approved revision: | 3707 |
| Merged at revision: | 3702 |
| Proposed branch: | lp:~alan-griffiths/mir/placement-notification |
| Merge into: | lp:mir |
| Diff against target: |
785 lines (+339/-8) 31 files modified
include/client/mir/event_printer.h (+2/-1) include/client/mir/events/event_builders.h (+4/-0) include/client/mir_toolkit/events/event.h (+13/-1) include/client/mir_toolkit/events/surface_placement.h (+47/-0) include/server/mir/scene/null_surface_observer.h (+1/-0) include/server/mir/scene/surface.h (+2/-0) include/server/mir/scene/surface_observer.h (+1/-0) include/test/mir/test/doubles/stub_surface.h (+1/-0) src/client/event.cpp (+12/-0) src/client/event_printer.cpp (+14/-1) src/client/events/event_builders.cpp (+18/-3) src/client/rpc/mir_protobuf_rpc_channel.cpp (+7/-1) src/client/symbols.map (+3/-1) src/common/events/CMakeLists.txt (+1/-0) src/common/events/event.cpp (+7/-0) src/common/events/surface_placement_event.cpp (+50/-0) src/common/symbols.map (+5/-0) src/include/common/mir/events/event.h (+2/-0) src/include/common/mir/events/surface_placement_event.h (+40/-0) src/include/server/mir/scene/surface_event_source.h (+1/-0) src/include/server/mir/scene/surface_observers.h (+1/-0) src/server/scene/basic_surface.cpp (+12/-0) src/server/scene/basic_surface.h (+1/-0) src/server/scene/legacy_surface_change_notification.cpp (+4/-0) src/server/scene/legacy_surface_change_notification.h (+1/-0) src/server/scene/null_surface_observer.cpp (+1/-0) src/server/scene/surface_event_source.cpp (+5/-0) src/server/symbols.map (+2/-0) tests/acceptance-tests/test_custom_window_management.cpp (+77/-0) tests/include/mir/test/doubles/stub_scene_surface.h (+1/-0) tests/mir_test_framework/stub_surface.cpp (+3/-0) |
| To merge this branch: | bzr merge lp:~alan-griffiths/mir/placement-notification |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Mir CI Bot | continuous-integration | Approve on 2016-09-15 | |
| Kevin DuBois (community) | Approve on 2016-09-15 | ||
| Gerry Boland | Abstain on 2016-09-15 | ||
| Chris Halse Rogers | 2016-09-13 | Approve on 2016-09-15 | |
|
Review via email:
|
|||
Commit Message
Plumb relative placement notifications through from a surface to the client callback
Description of the Change
Plumb relative placement notifications through from a surface to the client callback.
This doesn't contain the window management logic to generate the notification, but provided the infrastructure needed to deliver it to the client.
| Alan Griffiths (alan-griffiths) wrote : | # |
There's an implementation of the window-management side of this in lp:~alan-griffiths/miral/placement-notification/
| Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3705
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:/
Click here to trigger a rebuild:
https:/
| Chris Halse Rogers (raof) wrote : | # |
Is there a reason we're sending a rectangle rather than just the top-left corner coordinates? The client already knows the size of the surface.
| Kevin DuBois (kdub) wrote : | # |
The client knows the size via the 'resize' callback... I think it would be clearer if it was told its 'placement' rather than 'size' (so, I'd rather deprecate using 'resize' in favor of placement, which contains x/y and size)
| Chris Halse Rogers (raof) wrote : | # |
Well, it knows its size because that's the size of the MirSurface that
got created.
And ‘placement’ is strictly for parent-
surfaces - we'd still need a resize event (or most placement events
would contain a meaningless (0,0) for top-left).
| Kevin DuBois (kdub) wrote : | # |
needs info:
I got a bit confused about what the placement was relevant to, I assume its relative to the current position, and this event is to confirm that the placement request occurred?
+ surface_
why not include_
| Alan Griffiths (alan-griffiths) wrote : | # |
> needs info:
>
> I got a bit confused about what the placement was relevant to, I assume its
> relative to the current position, and this event is to confirm that the
> placement request occurred?
placement requests are relative to the parent, and so is the result.
> + surface_
> ${PROJECT_
>
> why not include_
I don't understand the question, what has include_directories got to do with adding source files?
| Alan Griffiths (alan-griffiths) wrote : | # |
> Is there a reason we're sending a rectangle rather than just the top-left
> corner coordinates? The client already knows the size of the surface.
placement may or may not resize the surface depending on the request parameters and the parent position on the output. I think it simpler for the client to await exactly one event for the placement than to await what could be either one or two.
| William Hua (attente) wrote : | # |
> > Is there a reason we're sending a rectangle rather than just the top-left
> > corner coordinates? The client already knows the size of the surface.
>
> placement may or may not resize the surface depending on the request
> parameters and the parent position on the output. I think it simpler for the
> client to await exactly one event for the placement than to await what could
> be either one or two.
+1 for this
Can we also document what the rectangle is relative to? i.e. is it relative to the client-requested position before server-side flipping or after server-side flipping.
We might actually need two rectangles... The widgets in GTK expect both the final rectangle position as well as the intermediate position (after server-side flipping, but before server-side sliding within the display boundaries). I'm a bit uncertain as to whether or not a single rectangle is enough information to infer what GTK needs.
| Alan Griffiths (alan-griffiths) wrote : | # |
> Can we also document what the rectangle is relative to? i.e. is it relative to
> the client-requested position before server-side flipping or after server-side
> flipping.
Documented that it is relative to the parent surface.
> We might actually need two rectangles... The widgets in GTK expect both the
> final rectangle position as well as the intermediate position (after server-
> side flipping, but before server-side sliding within the display boundaries).
> I'm a bit uncertain as to whether or not a single rectangle is enough
> information to infer what GTK needs.
I'm not entirely clear what the objective of this is. As implemeted in Miral the server tries a series of transformations and selects the first satisfactory result. Some of these transformations flip, some flip twice, some resize, some slide and some combine the above. That
To provide "the intermediate" I'd need to know the rules for calculating it in each scenario. (And these will get more complex with the incorporation of the "anchored in parent" constraints.)
| Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3706
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:/
Click here to trigger a rebuild:
https:/
| Gerry Boland (gerboland) wrote : | # |
Basic API looks suitable for Qt. But I am curious if a user repositions the surface, does the client get new SurfacePlacemen
| Alan Griffiths (alan-griffiths) wrote : | # |
> Basic API looks suitable for Qt. But I am curious if a user repositions the
> surface, does the client get new SurfacePlacemen
> the WM has initially sized & placed the child surface.
At present it is only providing a response to placement requests (either initial creation or clients applying a placement to an existing surface).
I don't expect users to be able to reposition e.g. menus (lp:1616818 notwithstanding). We would need to identify scenarios where it is appropriate to send notification of user actions.
| Chris Halse Rogers (raof) wrote : | # |
If toolkit authors want the extra info, sure.
+// auto const placement_event = mir::events:
Old detritus left in?
Otherwise seems fine.
| Alan Griffiths (alan-griffiths) wrote : | # |
> +// auto const placement_event = mir::events:
> placement_);
>
> Old detritus left in?
Fixed
| Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3707
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:/
Click here to trigger a rebuild:
https:/
| Kevin DuBois (kdub) wrote : | # |
> > needs info:
> >
> > I got a bit confused about what the placement was relevant to, I assume its
> > relative to the current position, and this event is to confirm that the
> > placement request occurred?
>
> placement requests are relative to the parent, and so is the result.
>
Ack, and added to comments, thanks.
> > + surface_
> >
> ${PROJECT_
> >
> > why not include_
>
> I don't understand the question, what has include_directories got to do with
> adding source files?
Apparently adding the header thusly helps with some IDE's.
| Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
https:/
Executed test runs:
FAILURE: https:/
None: 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:/
FAILURE: https:/
| Alan Griffiths (alan-griffiths) wrote : | # |
15:09:21 11: [ FAILED ] NestedServer.
15:09:21 11: [ FAILED ] NestedServer.

PASSED: Continuous integration, rev:3704 /mir-jenkins. ubuntu. com/job/ mir-ci/ 1706/ /mir-jenkins. ubuntu. com/job/ build-mir/ 2134 /mir-jenkins. ubuntu. com/job/ build-0- fetch/2196 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= vivid+overlay/ 2187 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= xenial+ overlay/ 2187 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= yakkety/ 2187 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= clang,platform= mesa,release= yakkety/ 2162 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= clang,platform= mesa,release= yakkety/ 2162/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= xenial+ overlay/ 2162 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= xenial+ overlay/ 2162/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= yakkety/ 2162 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= yakkety/ 2162/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= android, release= vivid+overlay/ 2162 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= android, release= vivid+overlay/ 2162/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= mesa,release= xenial+ overlay/ 2162 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= mesa,release= xenial+ overlay/ 2162/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:/
Click here to trigger a rebuild: /mir-jenkins. ubuntu. com/job/ mir-ci/ 1706/rebuild
https:/