This commit fixes a regression introduced by "window_layouter: add
dynamic screen handling", rendering the sub-division of screens in
columns and row unusable. The said commit removed a condition needed
for the correct window placement. This patch restores the condition.
Issues #3646
This commit adds dynamic switching in between different defined
screens via keyboard shortcuts, or by editing the rules file.
In the window_layouter package it defines per default ten screens,
reachable by pressing the screen key along with numbers 0-9.
Fix#3646
When resizing windows of clients that respond very slowly to resize
requests, the window's size sometimes snapped back to its original size
immediately after finishing the drag operation.
The problem was caused by the interplay of the layout rules (obtained
via the 'rules' ROM, generated by the 'rules' report) and the
temporary interactive state that occurs during drag operations.
The rules are updated only at the time of releasing the button to keep
the overhead while dragging the window low. However, when releasing the
mouse, the (now outdated) rules kicked back into effect, triggering
resize requests for the window to its old size.
The patch solves this problem by decoupling the dragged state of a
window from the physical release of the button. The button release
triggers a transition from a DRAGGING to a SETTLING state and programs
a timer. In the SETTLING state, the windows behave as in DRAGGING state,
giving the interactive geometry precedence over the rules-dictated
geometry. During this state, further responses of window-resize requests
may come in and are handled like dragging was still in progress. After a
timeout, however, the current window layout is conserved as a new rules
report and the state goes back to IDLE.
For clients that takes a very long time (in particular, VirtualBox when
resizing the desktop, which takes sometimes multiple seconds), the
snap-back artifact can still occur, but the effect is reduced.
This patch adds the missing propagation of the maximized state from the
layout rules to the internal representation of a window. Without this
patch this state could be toggled by clicking on the maximizer button
only.
It turns out that the commit "window layouter: allow floating apps to
resize" interplays badly with the interactive toggling of the maximize
state of windows. In contrast to the window geometry and stacking, which
is always updated through the rules-feedback mechanism, interactive
changes of the maximize state omitted this loop and instead took a local
shortcut. Because of this shortcut, the maximized geometry eventually
ended up as window size in the window's assign rule. So unmaximizing the
window failed to revert the geometry to its original state.
This patch removes this inconsistency. The maximize state adheres to the
official chain of commands through the rules mechanism now. The state is
now maintained internally without affecting the window's geometry and is
evaluated while generating the window layout only.
As a minor loosely related improvement, this patch prevents the
highlighting of resize handles for non-resizable windows.
Issue #3200
This patch improves the transition from an interactive window geometry
change (dragging a window element) to the point where the resulting
new layout rules come into effect. During this short time, no resize
request must be issued because such a resize request would be based on
stale rules.
Fixes#3227
This patch supplements the dragging state of window controls to the
window layout so that decorators become able to visually reflect this
state, i.e., pressing the title bar while moving a window.
Issue #3097
This patch improves the handing of new appearing windows for which only
a wildcard assignment - but no exact assignment - rule exists. In the
prior version, an interactively raised window would stay in front of
such a window, which is unintuitive. The new version applies the
to-front mechanism to unknown new windows. For known new windows (with
an exact assignment rule) their original stacking position is preserved.
This patch solves an off-by-one problem in the window-size calculation,
which resulted in sporadic artificial resize requests. In Sculpt, this
glitch caused flickering artifacts in VirtualBox windows caused by
superfluous guest desktop-resize handling.
Furthermore, the patch introduces the dropping of resize requests with
unchanged content.
This commit replaces the former floating_window_layouter with a new
window_layouter component that supports the subdivision of screen space
into columns and rows, the concept of layers, and the principle ability
to store window layout information across reboots. The latter is
accomplished by reflecting the component's internal state as a 'rules'
report to the outside.
Fixes#3031
