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 <aa...@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
