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.
Interacting with a shared monitor edge could be pretty jarring as it was very
easy to trigger a workspace change.
We add some (10px) negative padding to decrease the problem.
Ideally we wouldn't change window focus at all when moving the pointer to
another monitor. Unfortunately windows on a unactive workspace doesn't react to
pointer input (eg. scroll).
When the activate window is «stuck» we can preserve focus however. Otherwise we
select the top window on the newly active monitor.
An alternative would be to wait for button events to change workspace. This
could work okay, but the pointer wouldn't react to eg. window edges.
squash! workspace overlay: use motion-event
The motion-event is better suited to making sure the pointer is always able to
interact with the windows on a monitor.
Activating another workspace when moving scratch windows across monitors will
now cause issues. For instance moving a scratch window to another monitor with
they keyboard would reset focus back to the original monitor. So we simply let
the motion-event always take care of this.
- User drags scratch window from monitor A to B
- The B monitor overlay is not triggered and thus not removed (The grab seems to
prevent it)
- Not possible to interact with windows on monitor B until the mouse is moved
back to A and into B again
Note: The special check for is_on_all_workspaces is not strictly needed -
metaWindow.change_workspace seemes to have the same end-effect, but it seemed to
be more jumpy. Did not investigate further.
Note: Sometimes the moving window jumps just as it crosses over to the other
monitor - not sure why - but it might make sense to delay the monitor-workspace
activation until the grab ends.
if there is no column to the right and the rightmost column contains
only one window.
This allows freshly created windows to be stacked without
having to change focus.
space.targetX = Math.round(clone.targetX) + ... resulted in null when
clone.targetX was undefined. This could happend on extension startup and caused
the space to be unusable.
Initialize clone.targetX and remove duplicated space.targetX initialization.
Not exposed in the preference ui yet.
Can be set with dconf or in `user.js` like this:
var settings = Extension.imports.convenience.getSettings();
settings.set_string('default-background', '/path/to/image.jpg');
ref #83
Zoom is the default option in gnome when using pictures as the background image.
This is a much better default then what we've been using.
When using color backgrounds with noise we need to use the `wallpaper` style, as
the noise isn't designed for stretching.
ref #83
Runs X11 by default, pass in -w to run a wayland session. The dbus address is
copied to clipboard, so it's easy to connect to the new sesssion from emacs
using `gnome-shell-set-dbus-address`.
Depends on Xephyr in the case of x11, and xclip is used to copy the dbus
address.
Tor Hedin Brønner