It looks like mutter doesn't maintain override_redirect on wayland windows (ie.
it doesn't try to emulate the X11-only(?) concept)
This caused many menues (eg. gtk menues) to be registered by us (creating clone,
registering resize signals, etc.)
Particularily noticable in libreoffice - the menus was very delayed and
sometimes didn't show up at all. (Observed in GS 3.34.3, libreoffice 6.2.6.2)
(TOOLTIP is checked preemptively)
For some reason after a successful `move_frame`, and `position-changed`,
the window is moved back to it's original position. This only happens
sporadically...
Anyway, just do the simply thing and make sure all `position-changed`
signals are correct.
NOTE: need a grab guard or something for non-clutter dnd
Windows on a workspace can be placed on another monitor. Having the
clickoverlay active means it's impossible to interact with these
windows.
This is a quick fix to make the overview somewhat more acceptable when
using multiple monitors.
onComplete only runs if the animation actually finishes. While there
shouldn't be anything that runs a new scale animation on the clone, or
removes transitions. It doesn't hurt to be on the safe side and use
onStopped which is guaranteed to run, since the complete function is
essential.
ref https://github.com/paperwm/PaperWM/issues/248
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
Tor Hedin Brønner