Re: gamer mouse button shortcuts (LONG)
Am Samstag, 1. Oktober 2011, 09:59:34 schrieb todd rme: I gave a pretty length overview of how I think the current shortcut system could be improved here: http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-d evice.html I want to add another limitation of the current system: Mod4 (and higher) do not seem to be supported by Qt. They are extensively used by the (German) Neo layout [1], though. I have just added a note to https://bugs.kde.org/show_bug.cgi?id=208863 , although this bug report looks like one that could be easily forgotten about for a lng time (mentioning esoteric hardware / setups, not even officialy confirmed so far). Have a nice day, Hans [1] http://www.neo-layout.org/
Re: Re: gamer mouse button shortcuts (LONG)
On Sat, Oct 1, 2011 at 8:21 AM, Martin Gräßlin mgraess...@kde.org wrote: forgot to add kcd -- Forwarded Message -- Subject: Re: gamer mouse button shortcuts (LONG) Date: Saturday 01 October 2011, 08:19:47 From: Martin Gräßlin mgraess...@kde.org To: Kwin, NET API, kwin styles API, kwin modules API k...@kde.org On Friday 30 September 2011 15:14:10 Rick Stockton wrote: I've been inspired by the 'shortcut doc' Thread on kwin ML. This concerns mouse devices with extra buttons driving our desktop, and creating mouse-based shortcuts. snip long part - - - - - - So here's the questions: FIRST: If I (and maybe some helpers too) can crunch it fast enough for 4.8, would you all like to have it in there? Redesigning the effects KCM would be great but that is nothing for the 4.8 timeframe. It is nothing that I would do without a proper useability study and I am very much against copying the design of CCSM. I consider it us magnitiudes worse than our current KCM (which sucks but that's a different story). The CCSM gives focus on the large functionality and complexity of the system. This has to be hidden from the user. AFAIK not even Ubuntu (being the last relevant distro defaulting to Compiz) is shipping the CCSM by default. Especially something like mouse shortcuts have to be configurable in the same way as all other shortcuts. It would be unaccaptable to have a KWin only solution. My proposal: turn it around. First do adding the functionality for the shortcuts and in a later step add the GUI bits. And we should really look into getting it as a plain old shortcut. We should also think about waiting one more year and do a proper implementation with Qt 5 and KDE Frameworks 5. If it is possible to have the functionality in 4.8 without GUI I'm not against it. Having it work with editing the config file would be just fine for the users who really need it. SECOND: If so, when is tentative feature freeze? Feature freeze is documented here: http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule Soft Freeze: October 27th Hard Freeze: November 10th So a little bit more than a month. THIRD: Can I leave i10n, L18n issues in the hands of competent OTHER PEOPLE? If we don't do gui we can skip this part ;-) Cheers and thanks for your interest to improve the situation Martin I gave a pretty length overview of how I think the current shortcut system could be improved here: http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-device.html Short version: 1. Make it pluggable and device-independent. Developers could write plug-ins that allow any device to provide shortcuts. KDE applications would neither know nor care what the shortcut comes from, they would all be handled the same. Ideallt the API for shorcuts on the application end would stay the same. 2. The plugins could not be static, it would need to be possible to change its properties on-the-fly. This would allow backends to also provide KCM modules to change device-specific properties. 3. Allow users to set an arbitrary number of button combinations for a given shortcut. The currentl limit of 1 global and 2 local is problematic even for just keyboards. For instance if someone has a laptop with a multimedia keyboard, they cannot use their multimedia keys and at the same time have shorcuts that work when travelling. I could provide a mockup of an interface for this. I seem to recall someone saying that this is how it already works internally, there is just no GUI for it, but I could be remembering incorrectly. 4. (optional) Add a profiles systems to the shortcut handling. Users should be able to switch between different shortcut systems depending on the context. For instance someone would likely want a different set of shortcuts when a laptop is at home, on the road, doing presentations, or playing media on a TV. It could be activity-aware, with different set of shortcuts when writing a report than when watching a movie, for example. If this is too clunky to support generally it would be possible to support it on the backend side (so kremotecontrol could report different buttons to the shortcut system depending on the active kremotecontrol profile). 5. (optional) Add axis handling to the shortcut system. This would allow handling axes of devices (like joysticks, mice, and touch-pads) in a consisten manner, as well as mapping between them (using a joystick axis as a mouse or vice versus) and mapping buttons to them (like using the keyboard or remote control buttons as mouse or joystick axis controls). This would allow applications like games to transparently handle joysticks. 6. Initially, just port the current keyboard shortcut handling to this system. If the mouse support is ready that could be ported as well. Others could come later. As long as the plugin support is ready there would be no rush in porting already-working software. This approach
gamer mouse button shortcuts (LONG)
I've been inspired by the 'shortcut doc' Thread on kwin ML. This concerns mouse devices with extra buttons driving our desktop, and creating mouse-based shortcuts. SAD STORY You may recall that, many months ago, I was encouraged to try a Qt enhancement for this. Qt consumes X11 ButtonPress and ButtonRelease events for X11 button numbers greater than 9, doing nothing with them -- and NOT passing them up to the Window Manager when a programmer tells Qt to pass along the Button Events I didn't use. After a couple of 'false' starts, I had a design which could preserve binary BC; but it did not meet the time frame for the end of of Qt4 series, and I have been unable to obtain a contact a 'coach' about Qt input programming anyway / SAD STORY Back then, Aaron also gave a tentative thumbs up! to my fallback proposal: If we can't fix Qt to 'handle' ButtonPress and ButtonRelease events for the buttons which are greater than 9 (the Events can show a button as high as #31), we can still create some pretty amazing shortcut capabilities in kwin -- before QT-based Apps even have a chance to flush the events down the toilet. That is, *IF* you masters of Kwin and the KDE Workspace are willing to help me mess around with it. My Goal is to define new shortcut output commands as needed, to be at least as feature-rich as Compiz. We can provide vastly more usability, actually, by adding the the mouse button modifiers trick into the project. I know that the timeframe is short. I therefore suggest that we restrict these mouse-based shortcuts to the land of kwin 'global' and kwin-controlled window-specific rules. GUI PROPOSAL: *PART 1* Re-do our KCM module for desktop effects, using CCSM as a guide to the GUI implementation. (BTW, CCSM == CompizConfigSettingsManager. If you're not familiar with Compiz, you can play around with it in most Distros by running compiz --replace from a Konsole. You'll still be running KDE, and the only breakage I've noticed in my Distro, Mageia-1, occurs in the Panel: the KDE Panel desktop pager shows Compiz desktops, but Compiz uses virtual desktops to implement our scheme of desktops. Their design has two layers of Desktops, while we use only one. My panel pager contains only one desktop, because I'm doing all of my switching and cube-spinning is done among the more numerous virtual desktops.) In CCSM, each setting has TWO lines for defining the user's choice of input. We have only the wrench button to view/change the keyboard sequence which invokes the change (with the info button following the wrench button). Their first line implements keyboard shortcuts, almost exactly as our wrench. But their second line, with a mouse icon, implements a choice of buttons (with modifier keys) to execute the same effect. Even though the extra line take up more screen Real Estate,I like their scheme, because it separates the logic for both the user and the programmer: The keyboard shortcut, and whether it has been changed, or whether it is even enabled, is completely separate from the mouse shortcut. The row is associated with one kind of shortcut and one kind of input device, not two.) Can someone please join in this, to handle CCSM? BTW, I don't know the proper way to encode hand-off of a mouse-shortcut keyboard sequence (containing mutiple keystrokes) to a Window. *PART 2* Modify the Compiz mouse scheme to ALSO allow the buttons within the XI Version 1 mask (Raw Buttons 1-3, Left and Middle and Right) to function as 'modifier keys' for other buttons. (This is my best idea: it gives a mouse user with limited numbers of buttons a whole slew of additional virtual buttons.) For example: under my hand, it is very easy to hold down ButtonRight, the context button while doing another mouse action: scrolling Up/Down (two more Buttons), Scrolling Right/Left (two more Buttons), or pressing a side button. (I've got FOUR of them, even though Qt flushes two of them down the toilet if we ever hand them off to a Qt program.) Or pressing a top button-- I've got 3 more. For me, holding RightButton and spinning the up/down wheel would be a GREAT implementation of scroll in/scroll out. People with more flexibility could use ButtonLeft instead, or in addition to, my use of ButtonRight. For me, ButtonLeft is an easy modifier for only BackButton (AKA XButton1 which is Button #8 from X11), ForwardButton/XButton2 (Button #9), Button #10, and Button #11, Plus wheel up and wheel down (X11 Button #4 and Button #5). So, I'd end up with 5 scroll axis choices, and 12 additional, virtual buttons for invoking various effects and keyboard sequences. Most people with tilt-wheel mice would have 6 'pretty comfortable' scroll axis choices (I have a tendon problem which makes right-left with ButtonLeft a difficult combination for me. Except when typing text, I'd be able to pretty much drive my computer with just the mouse. PART 3, MAYBE: Should we re-organize
