miral should not change surface geometry because it got maximized
Bug #1628630 reported by
Daniel d'Andrada
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MirAL |
Fix Released
|
Medium
|
Alan Griffiths |
Bug Description
When a surface gets maximized, miral doesn't have enough information to set the surface position and size (aka geometry), thus it should not touch them.
1 - Shell might animate the window maximization. In this case shell can, for instance, interpolate the geometry between its current, restored, state and its maximized state.
2 - miral doesn't know the available desktop area. There can be for instance a panel on top and a launcher on the left edge limiting the available are that a maximized window can occupy. And those UI elements might not be backed up by MirSurfaces either, like in unity8.
Likewise when you restore a window from maximized state.
Related branches
lp:~alan-griffiths/miral/rework-handling-of-surface-state-changes
- Gerry Boland (community): Approve
- Daniel d'Andrada (community): Approve (test)
-
Diff: 425 lines (+137/-81)11 files modifieddebian/libmiral1.symbols (+1/-0)
include/miral/window_manager_tools.h (+2/-0)
miral-shell/titlebar_window_manager.cpp (+1/-1)
miral/basic_window_manager.cpp (+114/-78)
miral/basic_window_manager.h (+2/-1)
miral/set_window_managment_policy.cpp (+1/-1)
miral/symbols.map (+1/-0)
miral/window_management_trace.cpp (+8/-0)
miral/window_management_trace.h (+1/-0)
miral/window_manager_tools.cpp (+4/-0)
miral/window_manager_tools_implementation.h (+2/-0)
Changed in miral: | |
assignee: | nobody → Alan Griffiths (alan-griffiths) |
description: | updated |
Changed in miral: | |
status: | New → In Progress |
importance: | Undecided → Medium |
Changed in miral: | |
milestone: | none → 0.2 |
Changed in miral: | |
status: | In Progress → Fix Committed |
Changed in miral: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Following the same argument for removing policy from modify_window() that we applied in revision 347 I think it is modify_window() that shouldn't be interpreting state changes to imply resizing.
Moving that logic to before the call to handle_ modify_ window( ) in order to provide suggestions for position and size in the modifications argument will allow shells to customise the result. (We do that for surface creation already.)