Merge lp:~mir-team/mir/improved-tiling-window-mamagement into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Cemil Azizoglu on 2015-01-14 |
| Approved revision: | 2244 |
| Merged at revision: | 2223 |
| Proposed branch: | lp:~mir-team/mir/improved-tiling-window-mamagement |
| Merge into: | lp:mir |
| Diff against target: |
1550 lines (+1090/-305) 7 files modified
doc/demo_server_controls.md (+60/-0) doc/mainpage.md (+15/-1) examples/CMakeLists.txt (+7/-0) examples/eglstateswitcher.c (+97/-0) examples/server_example_window_management.cpp (+771/-0) examples/server_example_window_management.h (+95/-0) examples/server_example_window_manager.cpp (+45/-304) |
| To merge this branch: | bzr merge lp:~mir-team/mir/improved-tiling-window-mamagement |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Andreas Pokorny (community) | Approve on 2015-01-14 | ||
| PS Jenkins bot | continuous-integration | Approve on 2015-01-14 | |
| Cemil Azizoglu (community) | Approve on 2015-01-13 | ||
| Alberto Aguirre | Approve on 2015-01-13 | ||
| Alexandros Frantzis (community) | Approve on 2015-01-13 | ||
| Daniel van Vugt | Needs Fixing on 2015-01-13 | ||
| Robert Carr (community) | Approve on 2015-01-12 | ||
| Kevin DuBois (community) | 2015-01-09 | Approve on 2015-01-12 | |
|
Review via email:
|
|||
Commit Message
examples: extend the mir_demo_server's TilingWindowManager into something more functional
Description of the Change
examples: extend the mir_demo_server's TilingWindowManager into something more functional
| Daniel van Vugt (vanvugt) wrote : | # |
Looks like some fun.
Just a slight word of caution: When you do demonstrate fancy things in demos, it's helpful if as much of the core logic resides in Mir itself and not in the demo. So that future shells don't all need to reinvent the wheel. One of the main architectural decisions that distinguishes Mir from Wayland is that we (intend to) provide core logic for shells instead of mandating that everyone write their own each time.
| Alan Griffiths (alan-griffiths) wrote : | # |
> Looks like some fun.
>
> Just a slight word of caution: When you do demonstrate fancy things in demos,
> it's helpful if as much of the core logic resides in Mir itself and not in the
> demo. So that future shells don't all need to reinvent the wheel. One of the
> main architectural decisions that distinguishes Mir from Wayland is that we
> (intend to) provide core logic for shells instead of mandating that everyone
> write their own each time.
It is good to show that future shells are at least possible without access to internals and having this for folks to play with gives an idea of some of the pain points with the current API.
And yeah, there's PITA stuff here (that I think should be supported more directly by Mir). I intend to address that when we feel confident of the right APIs to commit to supporting.
| Kevin DuBois (kdub) wrote : | # |
LGTM. It seems useful to see what we can do (and show others what can be done) with the existing API. I hope that we would drive the public api by porting universally useful things to core mir from the examples (via acceptance tests).
| Robert Carr (robertcarr) wrote : | # |
LGTM. I think this provides a lot of useful guidance on how to continue refactoring core Mir components: Ill share an edited version of my thoughts from an email thread.
Investigating the me::WindowManager interface...it's easy to recognize a clump of methods:
add_session/
as paralleling the mf::Shell (SessionManager) interface to some extent. Though immediately we can recognize it as a clearer distinction of responsibilities: We no longer require the 'Window Manager' to act as the Surface factory, merely a Surface controller.
I think with this mindset we can perhaps see a good refactoring of SessionManager and the SurfaceFactory hierarchy. mf::Shell could be changed to parallel this me::WindowManager interface directly, and the factory responsibilities could be given to a new interface. The mf::Shell implementation could be given responsibility for adding the surface to the scene. Not only does this sort out the strange observer based flow in this branch[1] but it simplifies things such as the PlacementStrate
[1] The pattern used here of the window manager responding to observer notifications from the scene probably does not scale...as the window manager can not enforce that it is able to respond to an observer notification to enforce the correct policy before the compositor visits the scene to paint. Thus we will eventually have to migrate it to be a true view controller.
| Robert Carr (robertcarr) wrote : | # |
For purposes of conversational transparency ill share the older version of my thoughts too, though I think what I just wrote is more significantly succinct:
Hey Alan :) Thanks for leading this effort. I've been thinking about the me::WindowManager interface and how it connects to the rest of the system. I think it's a good step and more promising than surface wrapper...I think there's one sort of cleanup that should happen before its totally compelling though.
Scanning through me::WindowManager, the first methods which grab my attention are:
add_surface, remove_surface, add_session, remove_session, etc...
Then of course, I am reminded of mf::Shell and the SessionManager When you dust off those forgotten classes this flow looks kind of strange: from SessionMediator through mf::Shell which does some factory stuff and adds stuff to the scene which dispatches to some observers, observers invoke me::WindowManager which copies the session/surface map held by the mf::Shell implementation and has a grand time with the scene implementing policy. In addition to being complicated I think this is pragmatically problematic: In particular adding surfaces to the scene and then notifying the window manager seems vulnerable to races in terms of the window manager having time to act before the compositor visits the scene. Various locking strategies can solve this, but problems continue to arise as long as the window manger is the observer....
I think this is pretty easy to sort out though if we extract responsibilities from SessionManager. First we can extract the Session and Surface Factory role/roles. This factory can then be given to the session mediator. This will be a true factory and NOT responsible for notifying observers, giving focus to new surfaces, or even adding them to the scene! Now the mf::Shell interface is reshaped to look like portions of your WindowManager interface, e.g.
mf::Shell
{
add_session...
remove_session,
add_surface,.
remove_surface,
configure_
resize_surface, (assuming we had client initiated resize)
etc...
}
me::WindowManager could of course implement this. This object can then add surfaces to the scene as it wishes, and manipulate them as such. Elements which are common to all window managers have a representation in the protocol, and thus will be part of this mf::Shell interface. Shell authors are free to extend this interface in their implementation class to attach additional methods (e.g. drag and resize as they exist in me::WindowManager or unity::
In some ways this is a return to some of the original window management design in the sense that it proposes this object sitting in-between the front-end and scene acting as an enforcer of policy through a controller role. It features a few key differences though that I think will really clarify the code and make things easier:
1. Removal of the msh::Surface wrapper. Maybe you remember a model we used to use where msh::Surface would hold so called surface data which wasn't part of the 'inner core' e.g. SurfaceAttributes. This was to allow the implementation of surfaces which were not "Shell" surfaces and...
| Cemil Azizoglu (cemil-azizoglu) wrote : | # |
F11 key doesn't do anything for me. It was working in the previous versions, though resize, and move both work. Is it still working for you?
| Cemil Azizoglu (cemil-azizoglu) wrote : | # |
Also eglflash doesn't toggle for me. It comes up maximized and stays maximized - unless I resize it, then it starts toggling.
| Alan Griffiths (alan-griffiths) wrote : | # |
I guess it is confusing that eglflash comes up in a "restored" window that is the size of the tile.
On 12 Jan 2015 22:45, Cemil Azizoglu <email address hidden> wrote:
>
> Also eglflash doesn't toggle for me. It comes up maximized and stays maximized - unless I resize it, then it starts toggling.
> --
> https:/
> Your team Mir development team is subscribed to branch lp:mir.
| Chris Halse Rogers (raof) wrote : | # |
I think I've pretty consistently said that we should implement a window manager with what we've got and then pull obviously relevant bits into Mir core over time. As such, I approve of this general approach. (Have not yet done code review)
| Daniel van Vugt (vanvugt) wrote : | # |
(1) Please don't make eglflash do anything other than flash:
158 +++ examples/eglflash.c 2015-01-09 18:07:10 +0000
164 + mir_eglapp_
(2) These odd state transitions shouldn't be common to all eglapps. It results in such weird behaviour that it would be better placed in some kind of explicitly named mir_demo_
114 +++ examples/eglapp.c 2015-01-09 18:07:10 +0000
120 +void mir_eglapp_
(3) The class name "WindowManager" is a hack and really needs to be removed instead of reused. I've mentioned this several times over the years. Just once last year I slipped up and felt I had to implement a "WindowManager" class. But we don't and we should not.
"Manager" like "Controller" are poorly chosen abstractions that lead to poor designs that are difficult to work with. But I'm not the only one who says so. Further reading:
http://
http://
I don't expect to get sufficient votes to affect change on (3) but it's important and something everyone on the team should think about.
- 2235. By Alan Griffiths on 2015-01-13
-
eglstateswitcher
| Alan Griffiths (alan-griffiths) wrote : | # |
> (1) Please don't make eglflash do anything other than flash:
> 158 +++ examples/eglflash.c 2015-01-09 18:07:10 +0000
> 164 + mir_eglapp_
>
> (2) These odd state transitions shouldn't be common to all eglapps. It results
> in such weird behaviour that it would be better placed in some kind of
> explicitly named mir_demo_
> 114 +++ examples/eglapp.c 2015-01-09 18:07:10 +0000
> 120 +void mir_eglapp_
Fixed
> (3) The class name "WindowManager" is a hack and really needs to be removed
> instead of reused. I've mentioned this several times over the years. Just once
> last year I slipped up and felt I had to implement a "WindowManager" class.
> But we don't and we should not.
> "Manager" like "Controller" are poorly chosen abstractions that lead to
> poor designs that are difficult to work with. But I'm not the only one who
> says so. Further reading:
> http://
> advice.html
> http://
> I don't expect to get sufficient votes to affect change on (3) but it's
> important and something everyone on the team should think about.
I too have doubts about XXXManager, but "window manager" seems to have sufficient currency to be exempted as a "term of art".
- 2236. By Alan Griffiths on 2015-01-13
-
Avoid attempt to recursively lock
| Alan Griffiths (alan-griffiths) wrote : | # |
> F11 key doesn't do anything for me. It was working in the previous versions,
> though resize, and move both work. Is it still working for you?
Fixed
- 2237. By Alan Griffiths on 2015-01-13
-
Further reduce scope of lock
- 2238. By Alan Griffiths on 2015-01-13
-
Clearer code
- 2239. By Alan Griffiths on 2015-01-13
-
Remove redundant resizing code
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2236
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://
| Alexandros Frantzis (afrantzis) wrote : | # |
Looks like a good concrete starting point to trigger further thoughts and discussions about the architecture of our scene/model and how it ties with window management.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2239
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://
| Alberto Aguirre (albaguirre) wrote : | # |
Does what it claims to do.
It's a good showcase of the awkward APIs the shell has to use to do simple things, which hopefully guides our future architectural changes.
- 2240. By Cemil Azizoglu on 2015-01-13
-
On MacBook Pro, F11 is FN+F11. So don't use function key in the mask.
| Cemil Azizoglu (cemil-azizoglu) wrote : | # |
> F11 key doesn't do anything for me. It was working in the previous versions,
> though resize, and move both work. Is it still working for you?
Fixed.
| Robert Carr (robertcarr) wrote : | # |
*Opens sealed envelope over suspenseful drum roll*
*Reveals prediction of review votes on this MP to shock and applause*
Thank you, thank you, I'm here all week.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2240
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://
| Daniel van Vugt (vanvugt) wrote : | # |
(4) Preferably choose key combos already familiar to users, instead of:
45 + - Resize window: *Meta-mousewheel*
Normally Alt+middle_button
46 + - Maximize/restore current window (to tile size): F11
Needs a modifier like Alt or something. Because it's good behaviour to not steal keys that apps might use themselves (e.g. F11 usually means app-initiated fullscreen).
(5) I'm a little concerned that people see this as an alternative to my current and previous proposals. They do different things of course, so remember that. My branches provide WM logic that is immediately reusable (without any effort) by any shell in half the amount of code, with test cases, and also solve future problems of metadata, behavioural overrides and minimizing the footprint of future shells that just want to override a few things.
I understand this tiling work is still acting as a thought experiment, but it appears to be on track to never be able to catch up to what I've already proposed in all those metrics. Of course, not sure, and it's just examples, so not a blocking concern yet.
- 2241. By Alan Griffiths on 2015-01-14
-
merge lp:mir
| Alan Griffiths (alan-griffiths) wrote : | # |
> (4) Preferably choose key combos already familiar to users, instead of:
> 45 + - Resize window: *Meta-mousewheel*
> Normally Alt+middle_button
I'll look into this. You mean Alt+middle_button & drag I presume?
> 46 + - Maximize/restore current window (to tile size): F11
> Needs a modifier like Alt or something. Because it's good behaviour to not
> steal keys that apps might use themselves (e.g. F11 usually means app-
> initiated fullscreen).
OK, done.
> (5) I'm a little concerned that people see this as an alternative to my
> current and previous proposals. They do different things of course, so
> remember that. My branches provide WM logic that is immediately reusable
> (without any effort) by any shell in half the amount of code, with test cases,
> and also solve future problems of metadata, behavioural overrides and
> minimizing the footprint of future shells that just want to override a few
> things.
> I understand this tiling work is still acting as a thought experiment, but
> it appears to be on track to never be able to catch up to what I've already
> proposed in all those metrics. Of course, not sure, and it's just examples, so
> not a blocking concern yet.
I agree this isn't an alternative. "Tiling" is an experiment to see how well shells can do window management through our published API. Your "alternative" proposals work use internal APIs so it isn't clear how they can be used by "future shells" (you're welcome to add options to demo_server to clarify this).
IMO both this work and yours is likely to motivate changes to the public API to make it easier to use.
- 2242. By Alan Griffiths on 2015-01-14
-
Maximize/restore current window (to tile size): F11 => Alt-F11
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2242
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://
- 2243. By Alan Griffiths on 2015-01-14
-
Alt-middle_button drag to resize
- 2244. By Alan Griffiths on 2015-01-14
-
Remove old scaling code
| Alan Griffiths (alan-griffiths) wrote : | # |
> > (4) Preferably choose key combos already familiar to users, instead of:
> > 45 + - Resize window: *Meta-mousewheel*
> > Normally Alt+middle_button
>
> I'll look into this. You mean Alt+middle_button & drag I presume?
Done
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2244
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://
| Andreas Pokorny (andreas-pokorny) wrote : | # |
nice.
http://
^
If you feel the urge for a different layout/tiling strategies
| Alan Griffiths (alan-griffiths) wrote : | # |
> nice.
>
> http://
> ^
> If you feel the urge for a different layout/tiling strategies
That can be an exercise for the interested reader. ;^)

PASSED: Continuous integration, rev:2234 jenkins. qa.ubuntu. com/job/ mir-ci/ 2609/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/788 jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/788 jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/750 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 606 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 606/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 750 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 750/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -runner- mako/3879 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 16977
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/2609/ rebuild
http://