[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: High-Numbered mouse buttons
From:       Rick Stockton <rickstockton () reno-computerhelp ! com>
Date:       2013-03-25 16:17:48
Message-ID: 515078AC.9070401 () reno-computerhelp ! com
[Download RAW message or body]

 On 03/18/2013 12:27 PM, Thomas L=FCbking wrote:
> Can you provide a quick relation to kglobalaccel / KAction?
> I mean, kwin already has (custom) mousebtton interception (passively
> grabs buttons on at least inactive clients) and a -certainly
> improvable- way to configure them.
>

> So if this is to remain on KWin & X11 (for now, wayland fixes this
> automatically - at least for KWin) we could pretty much just add
> passive grabs for <random MB + modifier combos here> and deal them as
> it pleases us (hand them down to effects etc.) - that may take an hour
> or so at worst, but i thought the idea was to get this into
> KGlobalAccel into K/QShortcut and from there via kgloablaccel into
> pretty much each and every application automagically.
>
> Did i miss anything?

Thomas: You missed nothing. Except, perhaps that KGlobalAccel cannot be
built using the keyboard QKeySequence concept -- because there will be
no 'QMouseSequence', or resulting translation to 'QMouseShortcutEvent'
to Trigger a QAction.

But yes, whatever we have which now responds to MB, should be extended
to support all MB which the User desires to configure. Don't forget, I
want to include the capability of notion of "held down buttons" serving
as another kind of Modifier Key - allowing the User to provide
"modifiers" with just one hand. (In Qt5, the Qt::MouseButtons mask of
held-down Buttons is reliable for the entire width of Platform supported
Buttons - "Qt::XButton1", "Qt::ExtraButton5"Qt::ExtraButton7, and etc.).

With regard to KWin alone, this probably IS as easy as you say. Although
"1 hour" for you takes at least "20 hours" for me, I am MORE THAN an
order of magnitude less capable than you guys ;) .

See also - Reply to Martin's post (sending immediately, and CC to
plasma-devel), which wonders if this would be suitable GSOC material for
a vastly smarter and younger person than I.
>
> Cheers,
> Thomas

My thanks to you both (Thomas and Martin) for explaining errors in my
guesses.




>
> On Montag, 18. M=E4rz 2013 20:04:36 CEST, 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.
>>
>> 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:
>>
>> (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.)
>>
>
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]