This makes selection logic a lot more centralized and robust. In particular the
selection highlight will now consitently track the window clone.
Also introduce `showWindow` `animateWindow` and `isWindowAnimating` to wrap some
potentially changing structure.
This fixes (mostly) issues with layout of constrained wayland windows.
eg. (* marks the selected window) slurp B:
layout
column A* B
...
resize of constrained window B finishes (before A)
trigger new layout (since target was not met)
`allocateDefault` strive to keep A's height (yet to be changed)
causing A to get all the height
We still have problems when the slurping the last window X (while X selected)
into a column with two constrained windows.
- We never request the window's _current_ size again
- Each time a resize is requested we mark the window with the targets
- These are cleared IF the request cause a resize
- Some windows are constrained and does not resize even when request != current
- Resizes can be async
This means that layout sometimes reach the state where:
currentSize != targetSize
targetSize == window's marked target
Happens when
a. An async window get a new size and a subsequent layout happens very quickly
(before the window is actually resized)
b. A constrained window is laid out and both its actual size and "layout
size" is unchanged from last layout.
Ie. we treat a constrained window as using infinite long time to fulfill a
request that is constrained to the window's current size.
(a) probably doesn't happen very often (?)
(b) is nice to avoid assuming such size-requests have a non-trivial cost.
It does assume that a constrained window always responds the same way to
requests for size S. Which obviously is not guaranteed. A window is free to
change its constraints at any time.
A constraint change due to changing discrete size increments will most
likely trigger a resize though - which will trigger a relayout.
And since we can't subscribe to constraint changes and layout isn't done on
every action it's not obvious that we want a constraint change to suddenly
become visible either.
The first async resize that completes cause a new layout which run using the
other async window's old size. This breaks layouts that request specific
heights (eg. slurp).
Most visible when slurping third window.
+ missing semicolons and treating targetHeight the same way in case of
un-resizable windows
`Space.layout` not accepts custom "column allocators" (per column)
An allocator allocates the available vertical space of the column.
The default column layout allocates the vertical space proportionally to the
member's existing height, but strives to preserve the height of the selected
window.
During a grab the grabWindow's geometry is never changed (as this is very
jarring for the user) and the column is laid out accordingly.
The layout triggered from grabEnd cleans things up (eg. if the grab-resize freed
up space not possible to allocate without moving the grab window)
Pending changes/cleanups:
- Rewrite `deferLayout` hack
Resolves#62
`Space.layout` can cause a resize, causes a move_to, triggering `moveDone`
_before_ all layout animations are started. The actor and clones of the windows
to the right is swapped and subsequent layout animations are broken. (animating
the hidden clone)
Observable when slurping / barfing when there's 2-3 windows visible to the
right (NB: without the navigator visible)
EDIT: This fix assume layouts affecting the selected window run `ensureViewport`
manually if necessary, but note that `Space.layout` actually ensures the
selected window (although only when animating)
The assumption that every line was timestamped turned out to be wrong [1]
causing the skip filters to break (and distort the output)
Abandon timestamp and message on separate line. Print only the time part of the
timestamp to save horizontal space.
Goto mark when the it's already focused now selects previous (mru) window.
Quite common to just quickly check a marked window - more convenient to repeat
the binding instead of using super-tab.
Specifically fixes (only in v3.28) that built-in workspace animation is visible
when moving mouse between monitors (changing the active monitor).
This problem appeared in 18eb343, disappeared in a8b23aa, and
reappeared in 9389d90 (consecutive commits)
I assume that prior to 18eb343 our own animation was active during the workspace
change. 18eb343 prevented a bunch of animations that didn't have any effect from
starting. Eg. ensureViewport and layout when they don't change anything. No
("paperwm") animation is thus run when changing the active monitor.
The workspace animation (v3.28) can also be suppressed by using
wm._blockAnimations prior to changing workspace.
Doing this when the navigator is active is easy, but there doesn't seem to be
suitable signals to catch all cases. (eg. we can't force our "workspace-changed"
handler to run before other handlers)
PS: This fix does not work for dialog windows so they're still
"workspace-animated" on monitor changes.
Try removing the Navigator.navigating and inPreview checks. In those cases the
clone should be visible.
Without those checks (together with the clone.get_parent check?) dialogs created
during animation is not hidden.
Also note that the unmapped description in af362e was wrong - unmapped is only
true a short period after the window is created.
To reproduce: Close a window with a confirmation dialog while the minimap is
open (eg. gnome-terminal with a running program)
A umapped window is either
1. a window that has not yet been inserted into a space/the scratch layer
2. a window we don't manage (eg. dialogs) meaning its clone is unused and should
not be shown.
Note that it's not unlikely that we'll start to manage dialog-clones in the
future (#92)
This reverts commit 48ac0268f6.
Did not seem to resolve the issue and it sometimes causes windows to be stuck in
a "unmapped" state. Eg. when suspending, resuming and unlocking on ubuntu 18.04
gnome 3.28 windowEnteredMonitor is called on the visible windows - marking them
as unmapped.
Starting on the first window in a space, creating a new window and then closing
it would leave the user with the second window active instead of the first as
expected. This happened because we would never fix the stack order of the first
window.
If utils fails to load we're not getting proper error messages as we're using it
outside a try block. Use `log` instead.
SyntaxErrors still doesn't return a proper trace unfortunately, though that's
perhaps better fixed in tooling. The alternative would be to run `Reflect.parse`
on the module file in the catch block returning that error instead...
This reverts commit b138e9083e.
Revert "Fix fullscreen reactivity again"
This reverts commit d5bd0cf023.
This would've made it likely to trigger the mouse «freeze» on x11.
Before we fixed the clone's position everytime it was allocated, eg. whenever we
would scroll a pixel.
Insetad we listen on the WindowActors allocation signal, which happens far less
as we don't move the WindowActor around much.
If the selected window is still visible we don't forc alignment with the monitor
edges, making it possible to eg. center the first/last window with a touchpad.
In the case of overshooting the last/first window we could end up not having a
window under the pointer, resulting in going back to the starting window.
The code indicates that the intention was always to ensure at the end :/
This might be unnecessary, as I assume the clones will get garbage collected
automatically, but that does assume it's not part of the scene graph (ie. it
dosen't have a parent). Just as well to do it explicit.
After a99c151 the we caused lots of
meta_window_make_above: assertion '!window->override_redirect' failed
warnings in the log.
Most likely best to leave such windows alone.
`worspace:window-removed` runs after `focus` which means ensureViewport can get
us into a bad state. Remove any dead neighbours while we're fixing the correct
stacking order.
In particular when we had this setup, where the numbers is the stacking order,
and `2` isn't fully visible:
| 3 | 1 | 2 |
closing `1` would focus `2` and `ensureViewport` would start scrolling it into
the view. `layout` would then remove `1` resulting `2` moving further (the width
of `1`) to the left.
Tor Hedin Brønner