Moving a space to another monitor with different fractional scaling
will mess up the background scale/size. Simply recreate the background
when moving monitors.
closes https://github.com/paperwm/PaperWM/issues/247
Having an active clone can cause some overhead, even when the window is
hidden. This can be observed if eg. playing a video in a hidden
workspace: the gnome-shell process will use around 10% cpu (at least on
my machine).
While we don't want to destroy and create clones on demand we simply set
null out the clone's source, which have the desired effect. This seems
to work smoothly.
The direction used were never «correct». When scrolling down it's
natural for the workspaces to move down. This had gone unnoticed for a
long time, but hopefully not too painful for people who have become
accustomed to the way it's been working.
This used to trigger on button-release, to facilitate presses being
cancelable. However it never worked very well, and gnome shell generally
uses button presses to trigger actions.
Selecting the window under the pointer doesn't work very well when
gliding.
Simply ignore it for now, letting us always listen on the background in
wayland.
This could trigger after 3-finger swipe + tap for some weird reason,
resulting in a minimized scratch window gaining focus.
I've tried to test the action without success, not really sure what it's
even supposed to do. Lets disable it :p
Hiding the top bar doesn't change the workarea, at least in 3.34.
Having scale_y = 0 does change the workarea. In other words animating
the top bar means the workarea doesn't change immediately.
This can cause trouble when going from fullscreen to maximized, as the
workarea won't be updated early enough, giving the maximized window the
full monitor.
The animation isn't really that useful, so removing it is a viable fix.
In the case of user hidden top bar we still need to update the workare,
so we update the scale directly.
Also make the hideTopbar logic somewhat readable.
closes#220
Wrapping around is quite disorienting, and it's pretty quick to go
through all by holding down page up/down.
We should also remap super+home/end back to first/last workspace.
It's now possible to rearrange windows with the mouse:
Dragging the window up, or down, will scale its size gradually down.
When below a certain threshold it will pop out of the tiling leaving the
user free to attach it at any tiling edge.
If not dropped onto a tiling edge it will end up as a scratch/float window.
Running two layouts after each other on wayland can cause the second
resize to be lost.
So avoid doing an automatic layout on addWindow giving the calling code
better control of the subsequent layout.
It's possible for floating windows to appear on a monitor inhabited by
another workspace.
So always force floating windows onto the correct monitor.
ref #226
The monkey patched code in kludges wouldn't run on enable after eg.
unlocking as kludges.enable() happens after tiling.enable(). This left
us with too few workspaces.
