"gamer" mouse button shortcuts (LONG)

[Rick Stockton]

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 the "Workspace Appearance and 
Behavior" shortcuts versus the "Common Appearance and Behavior" 
duplicates, into a more sensible UI? Maybe I'm just stupid.... but I see 
that "keyboard and gestures" duplicate kwin 'effects', and some 
worksplace 'switching' items. The L&F is a lot different. Do these two 
GUI's involve significantly different code, Developed and maintained by 
hand, or do they basically populate their UI rows from identical data 
tables?

In any case, I would "vote for" a DB which could be indexed in at least 
two ways: The input which INVOKES the shortcut (showing shortcuts 
assigned to that particular combination), and the function/output of the 
shortcut (showing the input which has been assigned by the user to 
invoke that function. Currently, we are focused on the second way - so 
it's hard for users to see what shortcut combos are "available and 
unused", or how a particular shortcut might have different functionality 
under different KDE Apps, or Windows, or Global on/off scenarios. We 
only show possible conflicts AFTER they've typed in a 'conflicting' 
shortcut.

FUNCTIONAL PROPOSAL:

*PART 1* If (and ONLY if) this enhancement would be received favorably, 
I can quickly hack kwin to execute some "global" effects of my choosing 
on my own box. (Which already has a nightly git of kde-workspace built 
under my user, with another userid's env set to run it all the time). 
This would be totally without GUI definition or lookup of the shortcuts 
-- I'll just hard-code the recognition and resulting Action of some 
high-numbered mouse buttons, and "button-with-modifier-button" Effects, 
and verify that they work as I expect. (Which means, basically, that 
they work AT ALL. ;)

*PART 2* After receiving some coaching on the DB schema (I'll aks 
questions AFTER I succeed with Part 1), I'll convert my 'hack' into 
candidate Updates.

- - - - - -
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?
SECOND: If so, when is tentative feature freeze?
THIRD: Can I leave i10n, L18n issues in the hands of competent OTHER PEOPLE?