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.
There's no longer a reason to force `ensureViewport` here. In particular when
closing a window, the windows to the left won't wait for the windows on the
right before becoming reactive.
button-press on these buttons trigger a grab (GrabOp.FRAME_BUTTON).
Our grab handler run startAnimate which tracks the background -> the
button-press is stolen
Only happened for server-side-decorated windows (make sense that the grab is not
triggered for CSD windows)
Regression after: 5d0f037d3
Syncing clone positions to the frame on addWindow doesn't work for slurp/barf.
Do it in insertWindow before we `addWindow` and run layout.
fixes 6d51bc2c24
This avoids some ugly situations where dialog-type windows was very hard to
focus. Windows that lie below the tiling is usually not possible to click so one
would have to use alt-tab, the overview, etc..
Our own preference UI behaved like that :D (but only on X11)
Making them always on top isn't 100% ideal though - especially since transient
windows doesn't move when their parent move. (so they quickly end up above
other windows)
The search dialog of gedit is an example. Prior to this commit it would not stay
on top when gedit was moved away. It did "flash to the top" during animations
though..
Semirelated: #40
Simply check if the window is currently wide enough to be considered maximized.
Before we used `unmaximizedRect` to track maximized status. That is of course
brittle since the window can change size in many way. We cleared
`unmaximizedRect` in cycle-width (but it has been buggy for along time :P)
Note: using the size-changed signal is not trivial for this purpose: the signal
doesn't provide the previous size and it is async in wayland and synchronous in
X11.. (after running move_resize_frame)
We silently relied on a tween being active after layout when inserting existing
windows. Set the clone's initial position in `space.addWindow` before layout to
fix this.
Don't display "Failed to install..." warning when a first-user already have a
user.js config
Still track has-installed-config-template so it's possible to remove the user
config dir without it reappearing on each extenstion init.
Turning off fullscreen would desync `c.targetY` and `c.y`. Simply make the guard
robust by making sure they are synced before foregoing tweening. This should
work better than making sure that we're always syncing the target everywhere.
We also shouldn't need to tween when `widthChanged`, if the clone doesn't move
we should be able to activate the window. If the layout initiates a scroll
`moveDone` won't activate any windows anyways.
When clones are active windows can't take pointer input. 9389d90cc made it
possible to only activate windows who's clone isn't animating.
We can take advantage of this by not forcing `ensureViewport` when a grab ends
triggering a moveDone activating the grabbed window immediately if it ended in
an already correct position.
This ensures all mouse input is redirected to clutter.
As #80 shows, weird things can happen when mouse clicks occurs in the region of
a "visible" X11 window with a hidden actor.
Fixes#80
Apparently the tween isn't tecnically done when onComplete is run, so
`tweenCount`/`isTweening` isn't correct.
Checking `isTweening` the clones does work, probably since they're queued
before cloneContainer.
Removing `space.moving` broke a silent assumption used by `insertWindow`.
The problem is caused by not detecting layouts that doesn't scroll the space.
Detect it by guarding against any active tweens.
`space.moving` is obsolete so remove it. We already guard against starting new
animations with the same target in `move_to`, which means keeping track of the
«moving» window is unnecessary.
I also cleaned up the code a bit, removed a bunch of unused parameters.
The bug is a good indication why `space.moving` was pretty ad-hoc and bad:
Returning when `space.moving == metaWindow` assumed there was already a tween
running, which we didn't want to replace. Swiping breaks this assumption by
removing any existing tweens. So a swiping to a already «moving» window would
result in ensureViewport returning early, never calling moveDone.
Tor Hedin Brønner