More devices into the Shortcut system...

[Albert Astals Cid]

El Divendres, 23 de desembre de 2011, a les 14:06:27, todd rme va escriure:
> On Fri, Dec 23, 2011 at 12:57 AM, Albert Astals Cid <aacid at kde.org> wrote:
> > El Dimarts, 20 de desembre de 2011, a les 21:48:30, Rick Stockton va 
escriure:
> >> It is time for us to "Fish, or Cut Byte" on two alternative ways to
> >> introduce Mouse-Oriented Shortcuts into Qt5 and KDE-Next:
> >> 
> >> Todd RME has been suggesting a new design- oriented around DBUS.
> >> Unfortunately, I don't know how to do that coding. Todd, if your
> >> design
> >> gets a more favorable review from THIS group, within the next few
> >> days,
> >> I'll try to assist you in your work (as best as I can; I'm definitely
> >> not the brightest person here.)
> >> 
> >> As an alternative, I'm suggesting the idea of enhancing one or two of
> >> the existing classes: I'd prefer to enhance the current QShortCutEvent
> >> and QShortCut scheme, so that they can include Mouse Button events
> >> within a QKeySequence. (This will including the possibility of _only_
> >> one or more Mouse Buttons, with no keyboard event at all.) If that
> >> proves difficult, I could create new Classes to do this-- but I think
> >> I
> >> can use the 'hasExtendedInfo' trick which one of the smart Qt guys has
> >> used to handle a variety of Signatures in the  QtMouseEvent() code. I
> >> can work with *this* stuff on my own.
> >> 
> >> Please give opinions soon, as we have only 3-5 weeks before the Qt5
> >> API
> >> goes into soft freeze. After we have Mouse Buttons done, the same
> >> design
> >> could be extended to handle other input devices (joystick, multitouch,
> >> and so on.)
> > 
> > After reading this mail i feel like i don't have all the information to
> > give an opinion since i did not get any pointer to learn what is the
> > Todd RME DBUS design.
> > 
> > Albert
> 
> Please take a look here: https://bugs.kde.org/show_bug.cgi?id=171295
> Or here:
> http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-d
> evice.html

Those are two looooooooongs walls of text :D

> The short version of the idea is to extend the existing dbus-based
> keyboard shortcut system to allow developers to support other devices
> besides just keyboards.  Users would be able to install plug-ins that
> provide button press events from other devices besides just keyboards.
> 
> The dbus service would be very simple and generic, just providing a
> way to register or unregister devices and receive button press events
> from the plugins.  Things like configuring devices, deciding how to
> name the button presses, making sure devices of a particular type
> (like multiple keyboards) don't conflict, and other such issues would
> be handled by the plugins in whatever way is appropriate for the
> device.
> 
> The plugins wouldn't have to be physical devices, either.  They could
> be things like voice recognition (such as simon), time-based triggers,
> even online signals.  If someone wants to provide shortcut events for
> something, they just need to write the appropriate plugin.  Of course
> none of the plugins would actually do anything unless the user
> specifically associates an event with a shortcut, and button presses
> would be tied to individual plugins so no plugin could steal the
> shortcuts of another plugin.
> 
> The idea would be that systems like kremotecontrol, simon, even games
> looking to use joysticks buttons, could all work through the same
> interface, instead of needing the half-dozen or so radically different
> shortcut systems and user interfaces we have now.
> 
> Initially (i.e. for frameworks 5) this could all be behind-the-scenes
> changes.  Basically just create the dbus interface and port the
> keyboard handler to use it.  Once that is done, support for additional
> devices and changes in the gui to support them could come later.

Ok, so after half reading the walls of text and this email what i think that 
actually what you and Rick suggest are different but not exclusive, Rick 
suggests improving existing Qt classes so they can handle a few more cases, 
you suggest creating a new plugabble framework to handle "everything", if i 
was to choose i'd choose both :D But obviously i'm not the one choosing since 
i'm not the one doing the coding nor I am an expert in the field.

Cheers,
  Albert

> 
> -Todd