Merge lp:~alan-griffiths/miral/fix-1646735 into lp:miral
| Status: | Merged |
|---|---|
| Approved by: | Daniel d'Andrada on 2016-12-05 |
| Approved revision: | 466 |
| Merged at revision: | 466 |
| Proposed branch: | lp:~alan-griffiths/miral/fix-1646735 |
| Merge into: | lp:miral |
| Diff against target: |
167 lines (+60/-1) 10 files modified
debian/libmiral1.symbols (+2/-0) include/miral/canonical_window_manager.h (+3/-0) include/miral/window_management_policy.h (+10/-0) miral-shell/tiling_window_manager.cpp (+13/-0) miral-shell/tiling_window_manager.h (+2/-0) miral/basic_window_manager.cpp (+4/-1) miral/canonical_window_manager.cpp (+6/-0) miral/symbols.map (+8/-0) miral/window_management_trace.cpp (+10/-0) miral/window_management_trace.h (+2/-0) |
| To merge this branch: | bzr merge lp:~alan-griffiths/miral/fix-1646735 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Daniel d'Andrada (community) | 2016-12-05 | Approve on 2016-12-05 | |
|
Review via email:
|
|||
Commit Message
[libmiral] Allow the WM policy a say in inherited moves
Description of the Change
Allow the WM policy a say in inherited moves
Movement of window "trees" is an area that needs more test around it, especially when tips and menus are involved. I aim to get to that, but landing this could be helpful already.
| Alan Griffiths (alan-griffiths) wrote : | # |
I'd like Gerry's take on this too (see below).
> I would prefer if shell could give miral enough context information (eg, the
> available desktop area) so that it could make correct decision on its own. But
> maybe that doesn't match miral's API style.
>
> But confirm_
> something other than the available desktop area happens to affect this
> decision.
Exactly, my concern is that the "available desktop area" isn't a simple concept that MirAL can handle.
In the "tiling" case it is the tile associated with the window.
In Unity8 it is the available region(s) on any outputs (but not associated with any specific windows).
In a lot of window managers there's no constraint - windows can be moved offscreen.
> What I wonder is how much value miral is adding in this specific case (moving
> child windows) with this API. What's more work for shell: validating every
> single child movement or implementing inherited child movement on its own?
I'm imagining that qtmir can implement the "available desktop area" concept as needed by Unity8 and that there's no other work needed further up the stack.
| Daniel d'Andrada (dandrader) wrote : | # |
On 05/12/2016 09:07, Alan Griffiths wrote:
> I'm imagining that qtmir can implement the "available desktop area" concept as needed by Unity8 and that there's no other work needed further up the stack.
Yes, that's how I plan to do it.
| Gerry Boland (gerboland) wrote : | # |
Having the "available desktop area" concept as something in the shell-specific policy makes sense to me. Unity8 does have different requirements to a tiling WM in this area.
I like Alan's suggestion, let's see how do-able it is.

I would prefer if shell could give miral enough context information (eg, the available desktop area) so that it could make correct decision on its own. But maybe that doesn't match miral's API style.
But confirm_ inherited_ move() works as well and is probably safer in case something other than the available desktop area happens to affect this decision.
What I wonder is how much value miral is adding in this specific case (moving child windows) with this API. What's more work for shell: validating every single child movement or implementing inherited child movement on its own?