Alternative way to activate Menu (Super+RMB) #148
Replies: 23 comments 11 replies
-
|
I would be extremely happy if it would be possible to bind menus to mouse buttons. In fact, this was a key feature of Fly-Pie's predecessor Gnome-Pie. With Gnome-Pie it was not only possible to use Any Modifier+Any Mouse Button but also to bind a single mouse button. This is useful if you have one of these mice with plenty of buttons. Furthermore, there was a delayed binding which would show a menu if the mouse button was held down for a couple of milliseconds. This way you could also bind pie menus directly to your RMB (or even the LMB but then it becomes difficult to drag things around 😄). But sadly none of this stuff works (for good reason) on Wayland. This was only possible to all the security flaws of X11. The main reason to make Fly-Pie a GNOME Shell extension (and not a standalone application) was to circumvent some of the Wayland-related restrictions for "normal" client applications. Yet I haven't found a way to properly intercept mouse events to do things like described above. However, to be honest, I haven't search thoroughly as I was pretty sure that these global key bindings are managed by Mutter and all other input is directly sent to the client windows with no way to intercept it from an extension (would be kind of flawed security-wise if as possible...). Nevertheless, what you're suggesting looks somewhat promising. Was it possible to open the pie menu in your extension from any position on the window or only when clicking the window decorations? |
Beta Was this translation helpful? Give feedback.
-
|
There's also the Super+LMB which somehow gets intercepted by GNOME Shell to start window dragging. Would be great to find this in the source... |
Beta Was this translation helpful? Give feedback.
-
Yes, here is a short demo gif:
I am not very familiar with window management and the like so take everything I say from now on with a big grain of salt... But I don't think we'd be able to override the
The window menu opens / the 'show-window-menu' signal gets fired when you |
Beta Was this translation helpful? Give feedback.
-
This ofc only works for
|
Beta Was this translation helpful? Give feedback.
-
|
Ahh, I attached a mouse to my laptop and now Super+RMB works as you describe. For some reason I cannot summon the menu with the touchpad... There are also some other places where this wouldn't work such as the overview, the panel, or maybe the dash if you have it visible by using some extension. But anyway, you're right, this would feel well integrated. So it would be possible to replace this context menu with one of the configured pie menus. Btw, there is global.get_pointer() which gives you pointer position and modifiers (including pressed buttons). But we would have to poll this every few milliseconds and even the we would miss short clicks, I guess. But this is nearly the required API... |
Beta Was this translation helpful? Give feedback.
-
Yep, that was what I meant. An alternative /additional activation method instead / besides of a keyboard shortcut.
Do you mean GNOME's window menu or the pie menu from Tiling Assistant? I don't have a problem with opening the window menu on my notebook. If it's the later, then it's intentional (I guess). You open my pie Menu with RMB and activate an item with the release of that very same click (You don't need to hold Super though). On a laptop you can't hold the RMB, so you would immediately leave my pieMenu and not activate an item since you are still within the deadzone. (And you won't see it because I've delayed the visual appearance of the pie menu, like I requested in in the other discussion :) ).
Sorry, I don't really follow here. Why would you need to poll every millisecond? My idea is: You would just open the Fly Pie with the signals. The user doesn't need to hold |
Beta Was this translation helpful? Give feedback.
-
|
I meant GNOME's window menu. I use two-finger-tap to open the context menu usually and this does not open GNOME's window menu when combined with Super.
Sorry for the confusion: I was thinking about the possibility of a more general solution allowing to bind any mouse button with any modifier. This could nearly work with |
Beta Was this translation helpful? Give feedback.
-
Ah, I see what you mean now.
It works for me with super + 2 finger tap; maybe a bug 🤷 |
Beta Was this translation helpful? Give feedback.
-
|
I just did a quick test. Polling every 20 milliseconds is sufficient for me to capture even the shortest clicks I am able to perform 🚀 🖱️ GLib.timeout_add(GLib.PRIORITY_DEFAULT, 20, () => {
const [x, y, mods] = global.get_pointer();
if (mods & Clutter.ModifierType.BUTTON3_MASK &&
mods & Clutter.ModifierType.MOD4_MASK) {
log('click!');
}
return true;
});This is kind of hacky, but it would greatly improve the possibilities and usability of Fly-Pie! Performance-wise it should be neglectable, every 20 milliseconds isn't too much... |
Beta Was this translation helpful? Give feedback.
-
Cool, any plans when / where (in the settings) this will land in the |
Beta Was this translation helpful? Give feedback.
-
|
I guess it will take some time. Fly-Pie 8 will be released quite soonishly with a focus on GNOME 3.3x compatibility. Thereafter I will look into this one and your other feature request. But both will need quite some work. This one here will be tricky as Fly-Pie is currently using the "normal" GTK accelerator functions (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
I'll create an issue anyways and report there any findings. If you find another approach for binding mouse buttons, I would be very happy as this seems to be quite ugly... |
Beta Was this translation helpful? Give feedback.
-
|
Here we go: #149 |
Beta Was this translation helpful? Give feedback.
-
|
The plan to bind any mouse button + modifier does not succeed, as I have no way to prevent the original event. Basically, I can notice when the user issues Ctrl+RMB, but I cannot prevent the context menu from showing up. So I decided to attempt the approach proposed by you in the first place. I intercept Super+RMB on a window like you did and in all other places by directly intercepting the corresponding events on the I submitted an initial implementation of this feature to the
What do you think? In the coming days I check whether Super+LMB could be possible as well.... |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! I tested it out for a few minutes and noticed the following 2 things:
PS. I don't know, if you have a specific reason for having the version nr in |
Beta Was this translation helpful? Give feedback.
-
|
I've got a freeze/crash. Don't know, if it's related to Fly-Pie but there were some errors in the journalctl around that time (Didn't check the exact time of the freeze/crash). There were also errors from PS. I can no longer reproduce the crash. |
Beta Was this translation helpful? Give feedback.
-
Nvm, got a second freeze now. I found more errors from The second freeze happened after I toggled the |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the detailed feedback! Let's fix all of these bugs :)
I just pushed a fix for this one. Should be working again. It was a regression as I tried to work-around another issue: If you use the Super+RMB in Turbo Mode (that is: hold down Super, press RMB, move the mouse to an item, release RMB, release Super), you will toggle the overview as you released Super outside of Fly-Pie. Maybe a dirty fix is required which virtually releases the key if I notice that it is still held down when an action is executed...
The first issue is intentional, if we canceled the menu as soon as the initial RMB gets released, there would be no way of using the menu by point-and-click. The second issue seems to be that RMB is not registered if Super is still pressed. I guess that this can be fixed though!
The problem was (at least about a year ago), that the extensions app seems to re-download extensions from time to time. This would then override your git-based version. To prevent this, I am using a higher version number. But I could check whether that still happens...
Thanks for the report! I'll hopefully be able to reproduce this. If not, we might have to debug this on your end! |
Beta Was this translation helpful? Give feedback.
-
Nvm then, I've found a recent GNOME Shell gitlab issue, where someone reported a similiar problem (accidental downgrade) with a git repo. So I guess the issue still exists. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4807 |
Beta Was this translation helpful? Give feedback.
-
This does not work, the "real" button release still toggles the overview. I now reverted to the Fly-Pie 9 behavior: The menu will not close as long as a modifier button is held down.
This should be fixed now. I haven't been able to reproduced the freeze you mentioned. Maybe it got fixed by waiting until the modifiers are all released? |
Beta Was this translation helpful? Give feedback.
-
Didn't get any freezes since pulling this morning (after writing my comment 1h ago). Yesterday I got the 2 freezes within minutes of playing around with Fly-Pie. So (possibly), it's no longer a problem. |
Beta Was this translation helpful? Give feedback.
-
|
If tried to follow the code flow in Mutter and I think that we cannot intercept Super+LMB... Have you tried this before? |
Beta Was this translation helpful? Give feedback.
-
I believe, I did look for that code in GNOME Shell in the past but didn't find it... I guess it's completely handled in Mutter and probably can't be intercepted from an extension. But I am not a professional or experienced developer, so my opnion isn't worth much. Maybe try asking in a IRC/Matrix channel. You might be lucky and catch a GNOME dev or someone else who is knowledgable.
After trying the 2 versions for a few hours each, I definitely prefer the current behaviour over the one from this morning (where it was possible to accidently trigger the overview). It's more predictable. So everything works great for me. Thanks for the work 😀 |
Beta Was this translation helpful? Give feedback.
-
I already asked yesterday and got directed to the right location in the source. It basically starts here: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/core/events.c#L343
I'll test some more as well. I'll also test for potential regressions on touch screens in the coming days. As soon as I feel confident, I'll merge this! Thanks again for the suggestion! |
Beta Was this translation helpful? Give feedback.
-
|
I've noticed that rmb-ing (without [Edit] Looks like you just forgot the braces around the |
Beta Was this translation helpful? Give feedback.
-
|
Good catch! Should be fixed now. Always weird that |
Beta Was this translation helpful? Give feedback.
-
|
Touch screens seem to be working nicely. I'll merge this now, feel free to open a new issue if you encounter any new bug! |
Beta Was this translation helpful? Give feedback.
-
|
Nice, thanks for the work! |
Beta Was this translation helpful? Give feedback.
-
|
A problem with Super + RMB is that it is very common in the linux world that Super + LMB moves the window and Super + RMB resizes it, even if the second is not the gnome default. As such I have set it like that and it prevents fly-pie from activating on windows (on the desktop it still works). |
Beta Was this translation helpful? Give feedback.
-
Problem is that it's probably not possible to change
IMO, it is actually better because I don't need to bind Fly-Pie to a dedicated side button. I only need to bind If you do want to bind Fly Pie to a dedicated mouse side button, you can assign the side button to a keyboard shortcut and have Fly Pie be opened using that keyboard shortcut... (Not sure how common it is for side buttons to be able to simulate key combos though) |
Beta Was this translation helpful? Give feedback.
-
Quick search didn't produce easy way for me to do that on wayland. I am just getting converted to GNOME because of fly-pie, maybe I need to search more or go to Xorg. |
Beta Was this translation helpful? Give feedback.
-
Wow, that's a great compliment :) Sadly, the short answer to you suggestion is that binding something to mouse buttons is impossible in GNOME Shell. As @Leleat mentioned, the Super+RMB combination is an exception as this is intercepted by Mutter and extensions can override the default behavior (which opens the window menu). Other than that, there is no concept of window manager shortcuts involving mouse buttons on Mutter. Under X11, things are a bit different, though. Here, client applications can intercept any event (which is great for coding key loggers 😉). Therefore, binding menus to mouse buttons would be possible! However, I do not want to implement this directly in Fly-Pie, as it can be achieved quite easily with a third-party tool: xbindkeys. Here's a tutorial. Btw, another great X11-only tool is easystroke. I hope this can help you! |
Beta Was this translation helpful? Give feedback.
-
|
It sure does, thanks! I would figure the button out eventually, it's linux :) But, it's best if we have less struggles heh. |
Beta Was this translation helpful? Give feedback.
-
Currently you can only activate Fly Pie with a keyboard shortcut. It would be pretty cool, if there was a way to activate Fly Pie with just
Super+RMB. That way it would feel more integrated with GNOME sinceSuperis used as the main key all over the place. It would also add another activation method for an item. Instead of having to open the Pie with a shortcut, then dragging the mouse to an item and then clicking the item / waiting for a timeout, you could just directly open the Pie withSuper+RMB(on start of the press) and activate an item as soon asRMBis released.If you want to try out how this feels, I had a very basic pieMenu in my own extension (https://extensions.gnome.org/extension/3733/tiling-assistant/?c=114572). But I removed it in the latest version in favor of Fly Pie. So if you want to try it out, you need to install v23. Note that I only replaced the
Super+RMBon window since my pie menu was only used for window management. I didn't hooking into the Super + RMB on the Desktop.If you do want to implement this, these 2 files / functions seem to be relevant:
Beta Was this translation helpful? Give feedback.
All reactions