Re: More devices into the Shortcut system...
måndagen den 26 december 2011 01.36.47 skrev Albert Astals Cid: 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. Thanks Alberg for the high-level-overview! Altering Qt classes is going to be tricky since the feature-freeze in Qt is coming very very quickly. (mere weeks) So unless this can be done binary-compatible this change will likely have to wait for Qt6 ;) -- Thomas Zander
Re: More devices into the Shortcut system...
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 longs 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
Re: More devices into the Shortcut system...
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-device.html 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. -Todd
More devices into the Shortcut system...
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.)
