When walking the modal window stack upwards, we need to check if
the top modal window is still a descendant of the window that
the parent is blocked by. Fixes not all windows being brought to
the front when trying to active a parent in the middle of the
modal window stack.
* The parent information is necessary by the Taskbar to be able to
determine a modal window's parent
* Minimize and maximize modal window stacks together
This fixes a few problems with modal windows:
* If any child window, or any child window further down the
tree is considered modal, then all windows in that chain
are modal.
* When trying to activate a window blocked by a modal child
bring the entire stack of modal windows to the front and
activate the modal window.
* A window is modal if it has a parent and it's flagged as
modal, regardless of whether the ClientConnection has
created modal windows.
This technically supports diverging modal window trees as well,
where two modal windows share the same parent, allowing both to
be activated (including for input) but not the parent. And it
should also support modal window stacks of arbitrary depth.
This solves a problem where windows don't receive a WindowInputLeft
event when popup menus are opened. This prevented ComboBox being
closed when right clicking the application on the task bar.
Accessory windows are windows that, when activated, will activate
their parent and bring all other accessory windows of that parent
to the front of the window stack. Accessory windows can only be
active input windows. The accessory window's parent is always the
active window regardless of whether it is also the active input
window.
In order to route input correctly, input is now sent to the active
input window, which can be any accessory window or their parent,
or any regular window.
This allows marking a MenuItem as a default action, e.g. in a
context menu for an action that reflects what e.g. a double click
would perform.
Also enhance the window menu to mark the close action as the
default, and when double clicked perform that action.
Fixes#1289
fixes#2575
The extra ResizeEvent would be handled after on_rect_change, and would
reset the size of main_widget to what it was before the resize.
Bonus: Less unnecessary events.
Each window now has an associated progress integer that can be updated
via the SetWindowProgress IPC call.
This can be used by clients to indicate the progress of ongoing tasks.
Any number in the range 0 through 100 indicate a progress percentage.
Any other number means "no progress"
Instead, we now tell Windows to invalidate themselves. Window will then
pass on the requests to Compositor.
My basic idea here is that WindowManager should do window management,
dealing with incoming events, moving, resizing, etc. Compositor should
deal with painting the window stack in the right order with the least
amount of effort. :^)
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
2020-05-08 21:57:44 +02:00
Renamed from Servers/WindowServer/Window.cpp (Browse further)
