Merge lp:~alan-griffiths/miral/fix-1658085 into lp:miral
| Status: | Merged |
|---|---|
| Approved by: | Daniel d'Andrada on 2017-01-20 |
| Approved revision: | 493 |
| Merged at revision: | 492 |
| Proposed branch: | lp:~alan-griffiths/miral/fix-1658085 |
| Merge into: | lp:miral |
| Diff against target: |
169 lines (+105/-2) 5 files modified
debian/changelog (+1/-0) miral/basic_window_manager.cpp (+6/-1) test/CMakeLists.txt (+1/-0) test/raise_tree.cpp (+95/-0) test/test_window_manager_tools.h (+2/-1) |
| To merge this branch: | bzr merge lp:~alan-griffiths/miral/fix-1658085 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Daniel d'Andrada (community) | 2017-01-20 | Approve on 2017-01-20 | |
|
Review via email:
|
|||
Commit Message
[libmiral] top-level window is now raised along with its child (LP: #1658085)
| Alan Griffiths (alan-griffiths) wrote : | # |
> In the case described in the bug report, I get two raises:
>
> - First one containing kate's top-level window and its "Open File" dialog.
> - Then another containing juts the "Open File" dialog.
>
> I should receive only the first raise notification. The second one is
> superfluous.
>
> I suppose it should be easy for you to check if a window is already top level
> and thus avoid raising it?
In this simple case, yes. But consider:
A parents B,C
Z order is DCBA
Click on B
I expect Z order to be: BCAD
Which transformation, AFAICS can only be expressed with multiple notifications (both to the Mir model and to the Qt model). Vis:
advise_raise (ABC)
advise_raise (B)
| Daniel d'Andrada (dandrader) wrote : | # |
On 20/01/2017 15:53, Alan Griffiths wrote:
>> In the case described in the bug report, I get two raises:
>>
>> - First one containing kate's top-level window and its "Open File" dialog.
>> - Then another containing juts the "Open File" dialog.
>>
>> I should receive only the first raise notification. The second one is
>> superfluous.
>>
>> I suppose it should be easy for you to check if a window is already top level
>> and thus avoid raising it?
> In this simple case, yes. But consider:
>
> A parents B,C
>
> Z order is DCBA
>
> Click on B
>
> I expect Z order to be: BCAD
>
> Which transformation, AFAICS can only be expressed with multiple notifications (both to the Mir model and to the Qt model). Vis:
>
> advise_raise (ABC)
> advise_raise (B)
Indeed. But the question remains: Could you check if a raise is indeed
needed (ie, window in question not top-level) before issuing the raise?
A noop raise notification will bother the upper layers of the stack for
nothing.
| Alan Griffiths (alan-griffiths) wrote : | # |
To do that I would need to change the Mir interface to determine if a "raise" is a NoOp. I don't have direct access to the model.
| Daniel d'Andrada (dandrader) wrote : | # |
> To do that I would need to change the Mir interface to determine if a "raise"
> is a NoOp. I don't have direct access to the model.
Fair enough.

In the case described in the bug report, I get two raises:
- First one containing kate's top-level window and its "Open File" dialog.
- Then another containing juts the "Open File" dialog.
I should receive only the first raise notification. The second one is superfluous.
I suppose it should be easy for you to check if a window is already top level and thus avoid raising it?