Merge lp:~alan-griffiths/mir/tiling-window-mamagement into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Daniel van Vugt on 2015-01-06 |
| Approved revision: | 2191 |
| Merged at revision: | 2198 |
| Proposed branch: | lp:~alan-griffiths/mir/tiling-window-mamagement |
| Merge into: | lp:mir |
| Diff against target: |
528 lines (+477/-2) 5 files modified
examples/CMakeLists.txt (+1/-0) examples/server_example.cpp (+2/-1) examples/server_example_fullscreen_placement_strategy.h (+1/-1) examples/server_example_window_manager.cpp (+440/-0) examples/server_example_window_manager.h (+33/-0) |
| To merge this branch: | bzr merge lp:~alan-griffiths/mir/tiling-window-mamagement |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Kevin DuBois (community) | Approve on 2015-01-05 | ||
| Robert Carr (community) | Approve on 2015-01-05 | ||
| PS Jenkins bot | continuous-integration | Approve on 2015-01-05 | |
| Alberto Aguirre | 2014-12-19 | Approve on 2015-01-05 | |
| Daniel van Vugt | Needs Information on 2014-12-29 | ||
|
Review via email:
|
|||
Commit Message
examples: Add a (simplistic) tiling window management algorithm to mir_demo_server
Description of the Change
examples: Add a (simplistic) tiling window management algorithm to mir_demo_server
The tiling algorithm is more about being quick to implement than useful.
I'm not entirely happy with the hoops I went through to obtain information (e.g. look how I get the positions of the displays). But this does show that we can get the essential information needed through public interfaces.
| Alberto Aguirre (albaguirre) wrote : | # |
371 + static auto const description = "window management strategy [{tiling}]";
383 + if (!options-
This is misleading because the mir_demo_server help output implies that tiling is the default window management strategy. Maybe {none, tiling}?
| Daniel van Vugt (vanvugt) wrote : | # |
It's good mir_demo_server is distinguishing itself from mir_demo_
Although it sounds like "tiling" could become the defining feature here, so maybe we should rename mir_demo_server to mir_demo_
- 2185. By Alan Griffiths on 2015-01-05
-
merge lp:mir
- 2186. By Alan Griffiths on 2015-01-05
-
Code cleanup
- 2187. By Alan Griffiths on 2015-01-05
-
Code cleanup
- 2188. By Alan Griffiths on 2015-01-05
-
Extend WindowManager to have a "fullscreen" option
- 2189. By Alan Griffiths on 2015-01-05
-
Remove redundant --fullscreen-
surfaces option from server example - 2190. By Alan Griffiths on 2015-01-05
-
A (slightly) cleaner version
- 2191. By Alan Griffiths on 2015-01-05
-
Braces into window-manager options
| Alan Griffiths (alan-griffiths) wrote : | # |
> It's good mir_demo_server is distinguishing itself from
> mir_demo_
>
> Although it sounds like "tiling" could become the defining feature here, so
> maybe we should rename mir_demo_server to mir_demo_
I don't think the optional tiling window management is any more a defining feature than the optional glog logging - it just illustrates how to approach writing a window manager.
| Alan Griffiths (alan-griffiths) wrote : | # |
> 371 + static auto const description = "window management strategy
> [{tiling}]";
> 383 + if (!options-
>
> This is misleading because the mir_demo_server help output implies that tiling
> is the default window management strategy. Maybe {none, tiling}?
I'm not sure how to address this. The output was:
--window-manager arg window management strategy [{tiling}]
Which clearly doesn't show a default. That would be:
--window-manager arg (=tiling) window management strategy [{tiling}]
In any case we now have:
--window-manager arg window management strategy
Which might allay your concerns
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2189
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2191
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
A bit of downstream feedback:
<alan_g> Do you have an opinion on my example above? After writing my WindowManager example code think there's too much "wiring" in the example and not enough in the library. (I could push the "Tracker" and "Factory" wiring into Mir and give it a msh::WindowManger interface)
<greyback_> I do like the basic design of WindowManager, and think TilingWindowManager is a nicely written bit of example code. It is a bit surprising for me that different methods of WindowManager will be called in different threads tho, but as long as that's clearly documented it is fine
<greyback_> yeah the tracker is pretty typical, I had expected it to be in Mir
<greyback_> if you intend to push WindowManager into Mir, then yeah think it logical the Trackers will have to go in too
| Robert Carr (robertcarr) wrote : | # |
Ok to me.
I am imagining that this WindowManager interface if pushed in to Mir (or if this tiling WM example continued to grow) would gain configure_surface as a controller based alternative to the managed surface branch?
DisplayTracker stuff is weird :p I am thinking we could make msh::DisplayLayout more useful...e.g. ability to add an observer and query display conf by ID.
| Kevin DuBois (kdub) wrote : | # |
Okay by me, in that it shows we can actually swap out the placement of surfaces.
This will probably limit how often the overlay scenario is in use on the phone (as we currently cannot scale the surface as an overlay without a resize)
It seems like we're not requiring a single idea of the placement of surfaces. e.g. if the user doesn't call this:
250 + surface-
then there could be a split the idea of "where the surface is" into the idea in ms::BasicSurface, and the external tracking system that's being used.
To put another way, they could juggle the SurfaceId's to make a second surfacestack (and core mir loses the idea of where the surfaces are, what monitors its really on, etc). I'm okay with this in general (eg, if one wants to do a fancy custom graphics effect or something), but I'm not sure if we've spelled out the requirements to the users of what core mir needs to know.

PASSED: Continuous integration, rev:2183 jenkins. qa.ubuntu. com/job/ mir-ci/ 2525/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/664 jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/664 jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/638 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 522 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 522/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 638 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 638/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -runner- mako/3779 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 16750
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/mir- ci/2525/ rebuild
http://