Currently xfwm4 (4.10) only allows configurable keyboard bindings, not mouse bindings. This is a pain for users that wish to bind mouse buttons to xfwm actions such as 'tile window left/right' or 'move window to workspace left/right', which can only be assigned to keyboard hotkeys.
I am seconding this. I'd like to use the thumb button (mouse10) of my mouse to switch workspaces, but Xfwm will not let me bind mouse buttons.
Over at KDE, the equivalent bug (and it's many duplicates) is a 'top 10' feature request. I'm willing to poke at this, and see if I can add the functionality. I'm the person who added prerequisite support for high-numbered mouse buttons into Qt5.x, which also attempts to keep track of a full-width "mouse button mask" (rather than just the flags sent from X11: IIRC, the "modifier keys" + the ButtonPressed state of "Left" and "Right".) I know that GTK supports all the buttons, but I'll SWAG that it doesn't attempt to provide an accurate button mask to higher level applications. (The mask is complicated, and IMO not worth the effort within GTK if it isn't already there.) I was going to add these capabilities to KDE/Kwin and Plasma, but architecture decisions to favor "Activities" over "Desktops" made the project unpopular. And the Kwin leads had to do lots of bug-stomping in the migration to Qt5, because the QtScreen() class had a lot of unhandled error situations until very recently. I have no idea what Wayland presents in low-level mouse events (but I can learn.) I also have no idea of the GTK-X11 "stack being used by xfwm4 (e.g., using the xcb API, or using direct X11 calls, or some combination....) Now, within xfce: To be *ABSOLUTELY CERTAIN* that I do not interfere with extended button expectations on existing applications, I do not want to allow definition of 'Window Actions' using low-numbered buttons when the mouse position is within a Window: Only high-numbered buttons, and buttons combined with Modifier Keys, will be definable in the initial implementation. (That means: I would like to make the initial implementation work ONLY with high-numbered "gamer mouse" buttons when the mouse position is within a Window or it's decoration. (Even Button4 "Back" and Button5 "Forward" are heavily used in applications.) In theory, this shouldn't be problematic: we pass the button event to the "Windowed" App, it doesn't consume it, and it passes it back to us. But in practice, applications are buggy. Step 1: Implement "Desktop Switching via mouse buttons" on an arbitrary pair of high numbered buttons. Step 2: Create the settings API, storage elements, and GUI for such "mouse shortcuts". I'll be sure to make an arrangement in which modifier key+ mouse button combinations can be recognized rapidly. Step 3: Implement "Window Move" via button click - although I need to get some advice about what should happen to layout if the ending workspace contains Window(s) which the dragged Window will cover.) Step 4: Investigate the possibility of "modifier key + Drag" (RightButton or LeftButton) to drag at high speed, across Desktop margins. - - - - - I personally own an old Logitech G-700 (12 buttons configured as genuine buttons - not emulating keyboard commands). I do not have multiple monitors available, and cannot test commands which should involve Window movement or "desktop" flipping which spans multiple monitors.
OK, I looked at xfwm4 e3vent handling a bit. The code is "interesting". Someone has previously added a few lines which attempt to perform certain actions upon occurrences of "Button8" and "Button9". But events with those button numbers absolutely, positively cannot be received by this program. xfmw is using original xlib - WITHOUT the 'XInput2' extension. The single biggest defect in original 'xinput' design was a 2-byte mouse event signature, which didn't have enough bits to work with any high-numbered buttons. The xorg guys invented 'xinput2' to solve that problem. (They took care of some other issues too, but this was the impetus for doing it.) In order to do this enhancement, we need to build and run using the Xinput2 extension. I'm proposing that we do it only within xfwm4, and avoid delivering high-numbered mouse button events into application Windows which are expecting "legacy" 2-byte mouse event signatures.
(In reply to rickstockton@reno-computerhelp.com from comment #3) > OK, I looked at xfwm4 e3vent handling a bit. The code is "interesting". > Someone has previously added a few lines which attempt to perform certain > actions upon occurrences of "Button8" and "Button9". But events with those > button numbers absolutely, positively cannot be received by this program. Are you sure? If you're referring to the workspace switcher (window manager key + mouse 8,9), that might've been me. And I can assure you - it does work. :)
Wayland is irrelevant here, xfwm4 is not a Wayland compositor. The code in events.c shows its age, and indeed uses plain Xlib, not even XI2. Feel free to send patches to refactor the code in events.c and implement the feature you need. One thing I don't want to go into is per-app customization using name matching and the like.
(In reply to haarp from comment #4) > (In reply to rickstockton@reno-computerhelp.com from comment #3) > > <snip>.... But events with those > > button numbers absolutely, positively cannot be received by this program. > > Are you sure? If you're referring to the workspace switcher (window manager > key + mouse 8,9), that might've been me. And I can assure you - it does > work. :) YES, it does work. (I had guessed the "window manager key" to be 'Meta' and didn't try with 'Alt'.)
(In reply to Olivier Fourdan from comment #5) > Wayland is irrelevant here, xfwm4 is not a Wayland compositor. Right. But one long term strategy makes such a migration quite a bit more viable, in the very long term. > The code in events.c shows its age, and indeed uses plain Xlib, not even XI2. > > Feel free to send patches to refactor the code in events.c and implement the > feature you need. Three 'strategies' are apparent: #1 Upgrade into XI2, still using xlib. some "wrappers" could make this a bit easier, but my work would be large and error-prone WRT to several issues. #2 Move ALL input event queue processing to use XCB (We can *write* to screens using xlib for as long as we like, but the input queue for input events must be handled in one way, not two. (XCB is "better", IMO). A few "Wrappers" would be necessary here as well. But this strategy would allow me to lean on the the migration experience (and resultant coding) in kwin5, as examples and inspiration of how to re-code from xlib to xcb. #3 Try moving towards use of GDK3 classes? I'm not sure how deficient they would be, for writing WM code (although I see a few obvious omissions and errors). This would be a really radical choice, rewriting nearly everything, and I don't like it. > One thing I don't want to go into is per-app customization using name > matching and the like. Yeah, I _strongly_ agree with you. But don't client windows generally request to grab the mouse, while it's within their area, and use whatever facilities their toolkits or native xlib/xcb coding provides? (E.g., running an instance of xev on a current xfwm 'desktop' has no problems "seeing" XI2 events.)
(In reply to rickstockton@reno-computerhelp.com from comment #7) > (In reply to Olivier Fourdan from comment #5) > > Wayland is irrelevant here, xfwm4 is not a Wayland compositor. > > Right. But one long term strategy makes such a migration quite a bit more > viable, in the very long term. OT. It's not a migration, it's a rewrite that's needed. A wayland compositor is orders of magnitude more complex than a window manager, it has to deal with things that were previous dealt by the X server. Not something we can afford given the few developers we have - Unfortunate, but true, but that's not the end of the world either, X11 is not going away any time soon. > Three 'strategies' are apparent: > > #1 Upgrade into XI2, still using xlib. some "wrappers" could make this a bit > easier, but my work would be large and error-prone WRT to several issues. > > #2 Move ALL input event queue processing to use XCB (We can *write* to > screens using xlib for as long as we like, but the input queue for input > events must be handled in one way, not two. (XCB is "better", IMO). A few No, xfwm4 is based on gtk+/gdk which uses Xlib so we stay with Xlib - I don't want to have 3 different low level X11 API. And gdk has no plan to migrate to xcb. > "Wrappers" would be necessary here as well. But this strategy would allow me > to lean on the the migration experience (and resultant coding) in kwin5, as > examples and inspiration of how to re-code from xlib to xcb. > > #3 Try moving towards use of GDK3 classes? I'm not sure how deficient they > would be, for writing WM code (although I see a few obvious omissions and > errors). This would be a really radical choice, rewriting nearly everything, > and I don't like it. "GDK3 classes" ? xfwm4 is not C++ and will never be. But differences in gdk 2 vs. 3 aren't so big, gdk itself is not the issue migrating to gtk3, if taht's what you mean. > > One thing I don't want to go into is per-app customization using name > > matching and the like. > > Yeah, I _strongly_ agree with you. But don't client windows generally > request to grab the mouse, while it's within their area, and use whatever No, not at all, it's not how X11 works. Active grabs are rare, thanksfully. > facilities their toolkits or native xlib/xcb coding provides? (E.g., running > an instance of xev on a current xfwm 'desktop' has no problems "seeing" XI2 > events.)
Thank you both for teaching me several things! IIRC here's an apparent "issue" in migrating to XI-2: when you "get" the Cookie data, you are made responsible to "free" the data (fairly soon). If we read the mouse event Cookie data, we can't simply pass the event pointer to an application window - because the Cookie was "consumed" by us. I may be wrong, but I think we would need to reconstruct the original event as an entirely new event, with the original cookie data content duplicated and attached for the application window consumer to use (if they want to). That code would be slow and expensive. I don't want to do it - too much work, too error prone in the hands of someone like me. But it seems that all of the "gamer" mouse devices with large numbers of 'extra' buttons are provided with MS-Windows-based configurator tools, which let you convert the "buttons" from "button events" into "keyboard events". If redefined on Windows, I'm not sure whether the mouse devices are presented as both a "pointer device" AND a "keyboard device" in xlib, popping keyboard events which xfmw4 can "see" when a reconfigured button has been pressed or released. I will play with one of my devices, and report the results in another reply post. If the buttons can be made to present special keypress/release events from X11 core, then I need only define some really unusual keyboard combinations (i.e., combinations which are extremely unlikely to be significant within any "normal applications"), and then document what they are, so that owners can re-assign their "gamer" mouse buttons to deliver the assigned "strange" keyboard events. That coding is easy - well within my abilities. I'll do some reconfiguration to my own gamer mouse, and see what happens. Thanks!
This is slightly embarrassing after all my worrisome talk: I included the header <X11/extensions/XInput2.h> and added a few workspace switching actions to occur on the ButtonPress press of my high-numbered buttons ('Button10' thru 'Button14'.) They all work perfectly. But, like the existing mouse button actions, they're allhard coded in my basic test. I assume that the enhancement should be configurable. And, I have no idea what kinds of 'actions' would be popular. (In my little test, I made these buttons "hop" among workspaces, without requiring the mouse cursor to be outside a client window, or a modifier key to be pressed. Simply unconditional.)
I have slightly mis-handled this bug, which is supposed to be about 'settings': I have pretty much turned it into a bug about the capability of supporting high-numbered buttons (at all). I can send a small 'diff' which implements arbitrary workspace flips on 'high-numbered' buttons, including Button10. ('Done' per comment 2, as an unconditional workspace switcher - regardless of mouse location. No application can receive a 'Button10' event in this implementation. Shall I clone the bug and separate the issues? I'm not a 'real programmer', and I've got have no idea how to handle i10 issues within the settings module.
I just created new Bug 13474 to separate the two issues. That one has the attached patch for "support of high numbered mouse button events", with "Button10" implemented as an example. This is left as an unresolved enhancement for "settings".
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/112. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev