kwin "gamer" mouse buttons (was: "gamer mouse button shortcuts" )

[Rick Stockton]

A quick noticed to kde-core-dev: I will be writing fruther follow-ups to 
the only the "kwin" list, unless someone asks me to continue a CC: on 
the core list.

On 01/-10/-28163 11:59 AM, Martin Gräßlin wrote:
> 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.
Strongly agreed. I should have explained better- I WANTED to 
characterize it as "complete, fully functional". (But said something else ;)

>   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.
You can't do that, unless you have Qt "rights" to discuss design matters 
with actual Input device Developers. (A promise to offer such a contact 
was made and NOT kept; I've otherwise been ignored completely. Multiple 
times.)
Per my previous, I have a design which is both BC and functional for 
providing support within Qt. It would require additional API fucntions, 
and would therefore require a "Qt 4.9." I needed coaching about which 
plugins mattered, versus which plugins could be ignored. With no hints, 
no contact person, and nothing except some bad guesses made by Qt Devs 
on IRC .... I quit partway through the job. (It's QTBUG-19238; the 
tricky part is described in the final comment, dated of 01-Aug-2011.)

Last time I looked, 5.0/Wayland goes *** backwards *** : We actually 
**LOST** XBUTTON1 and XBUTTON2; it provides only LEFT, MIDDLE, RIGHT, 
and a primitive gesture scheme. Maybe updates have been done since I 
last looked, but I've been I hope that updates have been since I last 
looked.
>
> 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.
A+, thanks, I'll do it! But per above, the capability almost certainly 
probably ISN'T coming with Qt-5.0; and once 5.0 comes out (with a bad 
and API), the only way is probably the same "messy tricks" I would have 
done on 4.8 - with any contact or encouragement from anyone over there.
>
> 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.
I'LL TRY IT! And GUI-FREE certainly saves a ton of effort on my part. I 
assume that the config file in question is kglogalshortcutsrc (in the 
[kwin] section). Does this text string look OK as a scheme to initialize 
the cube via a single button Press/Release ("Button10"), and also the 
combination of RightButton "Down" (as a 'modifier') while clicking 
LeftButton? (In this case, I'm adding the two mouse button schemes to 
the default keyboard Methods of invoking the cube.)

"Cube=F7,Ctrl+F11,Button10,RightButton+LeftButton,Desktop Cube"

And finally: Does kwin receive mouse events for a Window which has 
"grabbed" the device, or do they go directly to the App Window itself 
(bypassing KDE completely?)
If they Bypass KDE, then we'll need a tiny Qt fix: For all Button events 
involving button numbers which Qt doesn't handle, pass them back up and 
through to "parent" windows -- instead of sucking them ALL in, and 
quietly destroying them.