amarullz / windowgestures Goto Github PK

As the title says, it is not appropriate to use gestures in overview and show applications.

It would be really great if you could add the ability to execute a custom commands so that users could invoke scripts upon mouse gestures.

This is similar to how Mac OS show desktop gesture and gnome-gesture-improvements implements this.

Behavior of windows is pretty much the same as described in one of my previous issue [#28], but now it is caused by workspace switching using four-finger swipe with Blur my Shell extension.

Gnome users can customize their keyboard shortcuts to do anything, and on my system I happen to map Super+D to something else. Using the show desktop gesture would activate my custom command rather than showing the desktop.

I think it's best that no gesture actions depend on certain keyboard shortcuts, so that the extension is compatible with any keyboard configuration. Is it possible?

(I'm not sure if this counts as a bug or a feature request, feel free to triage it as you see fit.)

I have recently switched from windows to Ubuntu so I'm used to switch between windows with Trackpad as I can actually see on which window I have to shift . The equivalent feature here is Alt Tab function. I would really love it if you can implement it in your extension. Your extension has really been helpful in transitioning from windows. Thank you very much.

This is the behavior similar to how Windows does horizontal switch window gesture or how gnome-gesture-improvements implemented it.

Current version works great with touchpad, thinking would be great to have all this stuff for touchscreens.

If I change the screen resolution, the behavior of the plugin becomes incorrect. I often connect my laptop to the monitor, so I have different resolutions and scaling. Because of this, I have problems with some gestures performed with four fingers, for example, with the gesture to open the panel. Other plugins also work incorrectly, for example, Dash to Panel.

The window switch UI seen in the middle is too small to be usable. An ideal window size would be 3-5 times bigger.
It looks like it doesn't respect my display's UI scale (display settings can be seen in screenshot)

Compiz alike magic lamp effect creates an effect when a window is minimized. This extension's gesture to minimize window comes with its own effect. When both are enabled, both effects are applied, which is not ideal.

Suggestion: Add an option to disable our minimize effect, compiz extension users can turn it on to avoid the conflict. Or preferably, automatically detect if the compiz extension is enabled and disable our effect.

I think this might be another feature, so I opened another issue.

As the title says, most gestures should not rely on the cursor/pointer position. Under pointer gestures seem to be suitable for touchscreen rather.

Would it be possible to add a pinch to resize function?
I think it would work similarly to how we can already pinch to zoom in and out of pictures and webpages, enlarging the content.

I guess the most direct comparison would be floating Picture-in-Picture windows on iOS and Android, which can be resized with two-finger pinch gestures.

I have tested it. Almost everything is great, but I can not let Show Desktop work. BTW it might be better to add some hint of Close Window, cause that might be an accidental touch.

https://github.com/amarullz/windowgestures/blob/2473192d5791fabc5a3a6c7e4ec83a7c93f61bb8/src/extension.js#L1824C25-L1824C25

I write and maintain the desktop icons extension, gtk4-ding. The show desktop action also hides the desktop icons window that shows the icons on the desktop. This kind of beats the point of showing the desktop.

Suggest-

_isWindowBlacklist(win) {
        if (win) {
            if (WindowClassBlacklist.indexOf(win.get_wm_class()) == -1 ||
                    win.get_window_type() === Meta.WindowType.DESKTOP) {
                return false;
            }
        }
        return true;
    }

In gnome we have only 3 finger gesture, but with this extension we can use also 4 finger gestures, but 4 finger up gesture is missing, so, I kindly request to add this up gesture for 4 finger.

Loving the extension so far but the most I am missing right now from Gesture Improvements is it used Ctrl+W for closing tabs. And I just got so used to that while browsing or any app with tabs. And it also works as closing the window most of the time even if the app doesn't have any tabs to speak of. Thank you for your efforts and keep doing a great job!

Does this extension work on Xorg?

On windows 11 you can configure an action for 4-fingers tap, I would like to do the same on linux.

I've experienced this issue multiple times when accidentally moving either the vesktop (discord) or zoom startup windows using the move gesture. I'm assuming that the move gesture doesn't account for the current window exiting.

Journalctl -r output when moving vesktop is listed below:

Apr 08 22:47:22 fedora kernel: gnome-shell[55741]: segfault at 18 ip 00007ff8302fe6e2 sp 00007ffd7bf10b40 error 4 in libmutter-13.so.0.0.0[7ff830252000+16f000] likely on CPU 10 (core 5, socket 0)
Apr 08 22:47:22 fedora gnome-shell[55741]: Trying to activate unmanaged window 'W5'
Apr 08 22:47:20 fedora dev.vencord.Vesktop.desktop[59591]: [3:0408/224720.681033:ERROR:browser_main_loop.cc(278)] Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Apr 08 22:47:20 fedora dev.vencord.Vesktop.desktop[59591]: [arRPC > process] started
Apr 08 22:47:20 fedora dev.vencord.Vesktop.desktop[59591]: [arRPC > websocket] listening on 6463
Apr 08 22:47:20 fedora dev.vencord.Vesktop.desktop[59591]: [arRPC > ipc] listening at /run/user/1000/discord-ipc-0
Apr 08 22:47:20 fedora dev.vencord.Vesktop.desktop[59591]: [3:0408/224720.426742:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
Apr 08 22:47:20 fedora dev.vencord.Vesktop.desktop[59591]: [3:0408/224720.426638:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
Apr 08 22:47:20 fedora dev.vencord.Vesktop.desktop[59591]: [3:0408/224720.075112:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
Apr 08 22:47:20 fedora systemd[2456]: Started app-flatpak-dev.vencord.Vesktop-59609.scope.
Apr 08 22:47:19 fedora systemd[2456]: Started flatpak-portal.service - flatpak portal.
Apr 08 22:47:19 fedora systemd[2456]: Starting flatpak-portal.service - flatpak portal...
Apr 08 22:47:19 fedora dev.vencord.Vesktop.desktop[59590]: Passing the following arguments to Electron: --ozone-platform-hint=auto
Apr 08 22:47:19 fedora systemd[2456]: Started app-flatpak-dev.vencord.Vesktop-59574.scope.
Apr 08 22:47:19 fedora systemd[2456]: Started app-gnome-dev.vencord.Vesktop-59574.scope - Application launched by gnome-shell.

Problem Reporting also reported this for zoom (exported from distrobox):

Apr 08 22:44:06 fedora gnome-shell[51104]: clutter_actor_add_child: assertion 'child->priv->parent == NULL' failed
Apr 08 22:44:06 fedora gnome-shell[51104]: clutter_actor_insert_child_below: assertion 'child->priv->parent == NULL' failed
Apr 08 22:44:07 fedora gnome-shell[51104]: Attempting to add actor of type 'StLabel' to a container of type 'StBoxLayout', but the actor has already a parent of type 'StBoxLayout'.
Apr 08 22:44:07 fedora gnome-shell[51104]: Attempting to add actor of type 'StLabel' to a container of type 'StBoxLayout', but the actor has already a parent of type 'StBoxLayout'.
Apr 08 22:44:07 fedora gnome-shell[51104]: Object St.BoxLayout (0x55c7c157f780), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55c7bf6239b0 ==
...

Edit: it also occurs when pressing alt + f4 while performing the move gesture on the current window. The move gesture not accounting for the focused window closing is definitely the root of the cause.

By searching through which plugin could handle gesture supports in Gnome 45, I found this one. I love your great work. However there are several features not very useful for me. I need a way to toggle features like:

1. reverse move window to left/right workspaces.
2. disable snap window to left/right
3. disable resize window

Well, another small thing: In my computer, moving a window and moving the cursor is not consistent. (My resolution scaling is 200%.)

Hi. First off, thank you for your work on improving Gnome's honestly lackluster gestures and making them amazing. Now, like many others, I was using the Gesture Improvements extension and am trying to move to this one for Gnome 45. Right out of the box I appreciate the added functionality of your extension, but there's a couple of pain points for me, which I think would be rather easy to solve on your end. First one is, when I set the 3-finger swipe down gesture to open Gnome's app drawer, the gesture doesn't correspond to a 1-to-1 action on the screen like all other gestures, but rather I have to complete the gesture and then I'm in the app drawer with no animation, which is jarring. Adding to that, there is no option for a cyclic overview navigation, so let's say I'm in the app drawer, swiping up with 3 fingers does nothing, I have to swipe down twice to go back to the main screen, whereas with GE's cyclic function I could just swipe up once and voila. These are pretty small, nitpicky things, but they are missing and I wanted to report on them so that your already excellent work becomes even better.

Again, thanks a lot!

Adding only to track things that gnome-gesture-improvements had implemented,
honestly don't see this personally as too important since most GTK4 apps already have overscroll navigation and chromium also supports this on Wayland if enabled using launch flags.

Allow to disable the behavior of making the window fullscreen when its already maximized

When an application, for expample, has unsaved changes, it will ask you about saving your work instead of instant closure. And if such application is closed by gesture, it will become invisible.

Snapping windows with gestures isn't working — neither when swiping up then to side nor when moving the window. Maximizing by the same means work properly.

Gnome 46, but it persisted on 45 as well

Is it possible to migrate the features of the unmaintained GNOME Gesture Improvements project to this one?

When I am using gestures for switching windows while having multiple external screens connected, there is issue with placing of UI element.

So when the action is completed, it sends a 'd' key to the desktop window, which actually starts a search and shows a box for all files on the desktop that have 'd' in them.., and does not actually show the desktop...

I don't think the shortcut is activated on most distributions, and the gnome settings allow you to bind that shortcut actually to any combination.

There should be a way to make this call directly...

Adding this just to keep track of things that gnome-gesture-improvements had implemented,
honestly I much rather prefer the move / resize window gesture that you have implemented, great work on this @amarullz !

Description The  windowgestures extension is not functioning on my Fedora system. After installing and enabling the extension, no window gestures are recognized and giving buggy response. 

Steps to Reproduce

1. Install Fedora 40.
2. Install GNOME 46.
3. Install the windowgestures extension version 7.
4. Enable the extension via GNOME Tweaks or Extensions app.
5. Attempt to use window gestures (e.g., swipe up to maximize, swipe down to minimize).

Expected Behavior The window gestures should perform the assigned actions smoothly, such as maximizing or minimizing windows upon specific swipe gestures.

Actual Behavior No gestures are recognized, and there is no response when attempting to use them. The extension appears enabled, but functionality is absent.

The 4 fingers up gesture is missing in the config (#22), but it's actually set to maximizing window by default. Because the config for it is missing, there's no way to change or disable that gesture either.

Now to move window "swipe down" gesture is used. But I want it to be a "three finger up", because "down" gesture conflict with "three finger down" gesture (I know, that it changes to up->down when moving windows by swipe down option is enabled. But it is quite inconvenient gesture. But if moving window will be possible by swipe up, the "three finger up" gesture, which currently used to maximize window, will not be needed, because when window "touches" the top of the screen, it automatically maximizes by GNOME shell. So to maximize window, you will need to swipe up as before, but it will happen faster than before and at the same time it will free up the "three finger down->up" gesture.

Sorry for my English and for possible mistakes, I wrote this in a hurry. Maybe I'll correct the issue later.

Screencast from 2023-10-11 15-01-35.webm
I am using DING extension for desktop icons in case that may be relevant.

Hi!

Some time ago I used to use touchegg on X11 which allows to move windows by dragging them with 3 or 4 fingers.

I really miss that feature and I believe it could be much appreciated.

Can you please consider adding that feature to your extension, please?

When a window is snapped to the left or right of the screen using the 3-finger move gesture and then subsequently unsnapped with the same 3-finger move gesture, the window size does not revert to the original size.

Workaround: Dragging the window using the title bar will revert the size to original.

How to replicate:

1. Snap window with the 3-finger move gesture (swipe down, then move)
2. Move the window again with the same gesture as above.
3. Note that the size of the window remains the same as when it was snapped.
4. Drag the window by holding the title bar and it will revert to its original (unsnapped) size.

Steps to reproduce:

• In Gnome settings, turn your touchpad sensitivity to fastest. Actually, the behavior is seen on the extreme slow end as well, but it's more convenient to test if the pointer is fast.
• Test Gnome's builtin gestures: 3 fingers up to overview, 3 fingers sideways to change workspace.
• Test our custom gestures.

Expected behavior: Gnome's builtin gestures and our custom gestures should behave similarly.

Actual behavior: Gnome's builtin gestures do not depend on touchpad sensitivity. Whether you set your touchpad to extremely slow or extremely fast, Gnome's builtin gestures are just as sensitive as they are out of the box. But our custom gestures do depend on touchpad sensitivity.

I don't know whether I'm reporting a bug or requesting a feature. It depends on whether you see Gnome's behavior as intended or a bug. On one hand, it doesn't make sense if gesture sensitivity doesn't depend on touchpad sensitivity, they are obviously related (fyi, on KDE, gesture sensitivity does depend on touchpad sensitivity); but on the other hand, I actually find Gnome's behavior useful. I wish that you could make our custom gestures behave just like Gnome's builtins.

I really enjoyed using your extension, but my system automatically upgraded to gnome 46 and now I'm frustrated as I can't use it

Hey @amarullz,

I went through your code. I noticed code format is all over the place. I would suggest to implement code quality tooling e.g. prettier and eslint.

I can make a PR for it if you need help with that.

Otherwise I would like you to thank you for work on the project.

Cheers.