High-Numbered mouse buttons

[Rick Stockton]

On 03/18/2013 12:46 PM, Martin Graesslin wrote:
> On Monday 18 March 2013 12:04:36 Rick Stockton wrote:
>> This is _partly_ WRT Compiz/Kwin inter-operability, but only at the
>> highest level (hence the new Thread).
>>
>> I suspect that nearly all users of Compiz/Kwin inter-operability do so
>> for one reason: Compiz supports the selection of High-numbered mouse
>> buttons for Desktop Effects, while Kwin does not.
> Personally I doubt that and from the feedback I got over the last years there 
> seem to be no Compiz users with kde-workspaces any more. From what I heard 
> from users most were actually missing the crl+alt+lmb for cube activation. I 
> have heard the shortcut thing a few times but users who need that seem to be 
> able to use xbindkeys.

Yes, the relevant bugID is # 96431, and there are more comments about
low-numbered Buttons (with Modifiers) than high-numbered Buttons. I'm
grateful for your more expert assessment.

>
>> If I'm right about that, then a small project comes to mind for
>> Kwin-future (on Qt 5.x, KF5) - because I have quit on creating "Mouse
>> Shortcuts" within Qt: The pretty massive effort just wouldn't seem to
>> save very much coding at the 'user program' level.
>> Within KDE applications and Kwin, however, "Global" and shared-default
>> "Application" shortcuts DO seem to be worth enhancing, as we move
>> forward to KF5-based Releases.
>>
>> Here's a mini-project for KWin, which I would be happy to try a bit
>> later into the 4.11 Development cycle:
> I think the focus should clearly be on KF5. So whatever you work on: best 
> check that it will be compatible. I know that for example KAction got moved to 
> kde4support and global shortcut handling somehow changed, but I do not know 
> exactly how.

I agree that "the focus should be on KF5", and modify "the plan" to
start right there (and be executed by someone with more ability than I).

WRT KAction/QAction: (And warning: I may not understand these changes
correctly): if I did understand what I've read in various places, then
KAction becomes Deprecated and moved into "kde4support". In new code,
the Parent QAction Class should be able to provide a complete
replacement - for handling Keyboard Shortcuts. But - in 5.0, QAction
cannot be used in QML without hand-written interfaces to C++ code. But,
with 5.1 and higher, GUI Applications can be given a new
application-wide "hidden frame" child of the Application itself - and
(If I understand this correctly)  unhandled QKeySequence instances can
float upwards through various "parent" layers of QML UI, to be
intercepted by a QAction defined on an instance of that "hidden frame"
Class. But I don't understand it, and may be TOTALLY WRONG in this
characterization.

QAction API provides for it to be triggered by QKeysequence - there will
never be a 'QMouseSequence' equivalent to that Class, or it's resulting
Event Types. Whatever KDE uses to intercept mouse events already, (basic
testing for Event Type and characteristics) should simply be extended to
perform Event-Filter-Like behavior with more complicated "match"
capabilities.

In any case however, I agree: Since it is not "THE major reason people
liked Compiz", then it can be part of Workspace/Kwin on KF5 "first-out",
or moved into the "KGlobalAccel" scheme as a new section (separate the
"mouse buttons" from "gestures" and "keyboard accelerators") -  or
perhaps added in a later minor Release, if the scope of work for
"First-Out is already becoming too large.) Recommendations?

Would this, as a "reorganize and extend mouse shortcut UI and behavior" 
project, be suitable GSOC for You, or Thomas Lübking, or another person,
to mentor)? I can draft bullet items for such a project (for your review
and repair), if a qualified "mentor" is available and you feel that the
time frame is correct..

Thanks either way!

>
>> (1) Create a suitable 'Global Configuration' scheme for matchable
>> buttons events in "System Settings". (Note to self: keep in mind that
>> the scheme must be compatible with later use in all kinds of
>> "Application shortcuts").
>>
>> (2) Select KWin effect which are suitable for invocation by
>> "High-numbered Buttons" (with/without simulaneously held modifier keys).
>> Be careful to check the resulting list against Compiz features, because
>> we need to cover as many of the reasons for "I use Compiz 8.6.x" as
>> possible.
>>
>> (2) At the same time, implement a scheme for Kwin to read and use those
>> settings as triggers for "appropriate" effects. (Note to self: KWin must
>> check for some "WM effect" Triggers before any QT processing occurs, I
>> will need to write a few more lines into the XCB <--> Qt Button events
>> routines.)
>>
>> (3) Creat GUI in KWin's "System Settings" code, so that "high numbered"
>> Button events can be saved/read according to the scheme created at (1).
>>
>> Maybe this should consist of a pick-list of buttons, rather than a
>> 'Click whatever you want to use' type of interface? Or would the current
>> method work, merely by allowing it to listen for more Buttons? (I don't
>> know anything about KCM.)
> The Plasma mouse actions have some GUI configuration for mouse buttons and 
> mouse buttons + modifiers.
  yes, I found them via context menu. Not much there. I can configure
and use "Horzontal Scroll", with or without Modifier keys, but XButton1
and XButton2 don't work.
>  So I'd say that would be a good start to look there 
> and just slam the code into the effects (erm move to libkworkspace to make code 
> sharing possible - on the other hand the Plasma code will be kicked anyway, so 
> duplication till KF 5 hardly matters).