"gamer" mouse button shortcuts (LONG)

[todd rme]

On Sat, Oct 1, 2011 at 8:21 AM, Martin Gräßlin <mgraesslin at 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 <mgraesslin at kde.org>
> To: Kwin, NET API, kwin styles API, kwin modules API <kwin at 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 would not only benefit mice, it would benefit remotes,
joysticks, bluetooth devices, speech recognition, touchpads, and even
keyboards.

An important use that I realized since I wrote this is using your
smartphone to control your computer over wifi.  A shortcut backend on
your compute paired with a frontend on your phone could allow for a
great deal of control.  There are a ton of programs like this for
android at least, but on KDE this could be handled transparently in
the background rather than needing some clunky add-on program to
configure it.

This approach would also make it easier to handle changes in the
underlying technology, since you could just rewrite one backend rather
than the entire shortcut stack.

Finally, things like games would be able to mostly use the existing
shortcut system for configuring how joysticks and joystick buttons are
handled, they wouldn't need their own joystick button handling,

-Todd