KAction and KShortcut in frameworks

[todd rme]

On Thu, May 10, 2012 at 11:21 PM, Mark <markg85 at gmail.com> wrote:
> Hi,
>
> Making this quite detailed and long mail as per request from David Faure
> (twice) ;)
>
> So, I've been patching KShortcut up to support multiple
> shortcuts: https://git.reviewboard.kde.org/r/104801/ and it's working just
> fine with that patch. However, there seems to be some duplication between:
> KAction - QAction
> http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKAction.html
> http://qt-project.org/doc/qt-4.8/qaction.html
>
> KShortcut - QShortcut
> http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKShortcut.html
> http://qt-project.org/doc/qt-4.8/qshortcut.html
>
> So lets go back to the basics here and see what is actually required
> (K/Q)Action in KDE.
> - QAction functionality as a base
> - Global shortcuts
> - Reset to defaults
>
> I don't know what setShapeGesture and setRockerGesture are supposed to be
> since they have 0,0 documentation. So i'm assuming (for now) that they are
> useless.
>
> As for "reset to defaults", i don't think that should be stored in a KAction
> abject. That feature is only usable in the Shortcut Editor (assumption) so
> having this for every single KAction in all KDE applications is a bit
> strange. Since the KAction has a name as well (back button, forward button
> ... just look at Shortcut Editor) it becomes fairly easy to simply store the
> default shortcuts in some config (KConfig stuff) file somewhere. So we don't
> need "Reset to defaults" in KAction. That only leaves Global shortcuts that
> are not base functionality thus have to be added.
>
> Note: i actually suggested the inclusion of global shortcuts in Qt by
> default. Sadly my knowledge and time was way to limited to implement that.
> If it had been implemented then we could have completely dropped KAction and
> KShortcut. Right now it's on the "radar" of the Qt devs (Thiago actually)
> but i don't know if this is something that will come in Qt 5.1. Not really
> expecting it actually.
>
> KAction is now defined:
> - QAction as base
> - add functionality for global shortcuts
>
> Global shortcuts are another story. There is KShortcut, but i really don't
> see a point in keeping the current "primary/alternate" (thus only 2
> shortcuts) option alive or even supported. I above mentioned patch in
> reviewboard is already adding support for multiple shortcuts.For frameworks
> i actually want to go a step further. Or a big jump.
>
> Completely get rid of KShortcut and introduce 2 new classes:
> - KInputShortcut
> - KInputSequence
>
> Right now it's not possible to make shortcuts that use both your mouse keys
> and your keyboard keys. For example keeping control pressed and pressing the
> mousebutton - something that on windows is quite frequently used to select
> some fiels (like in excel),.
>
> == KInputShortcut ==
> The same as http://qt-project.org/doc/qt-4.8/qshortcut.html only with input
> from all attached devices.
>
> ==  KInputSequence ==
> The same as http://qt-project.org/doc/qt-4.8/qkeysequence.html only with
> input from all attached devices.
>
> Back on the global shortcuts for a second. I might be hitting a little snag
> there. How are we going to tell that a shortcut is global?
> Perhaps like this:
> QList<KInputShortcut>
> And a  getter and setter for KInputShortcut:
> bool KInputShortcut::isGlobal()
> KInputShortcut::setGlobal(bool)
>
> The list would be passed in
> KAction::setShortcuts(const QList<KInputShortcut>& shortcuts).
>
> However, doing this would be easier but you lose the option to set a global
> shortcut:
> KAction::setShortcuts(const QList<KInputSequence>& shortcuts)
>
> So (for now) i would say: getters and setters for both KInputSequence
> and KInputShortcut. Not very sure about this part yet. If KInputShortcut is
> used then the user can provide the option to make it global or not.
> If KInputSequence is used then the shortcut is just as is and is local only.
> Not a fact, just my idea.
>
> As for the current KShortcut and KAction. If you all like this idea and
> would include it in frameworks if implemented correctly then i would like to
> fully deprecate KShortcut in KDE 4.9 (removed in frameworks) and partly
> deprecate KAction where needed. If this idea is accepted then i'm not very
> sure about my earlier patch anymore. Since that seems somewhat temporary if
> we go by this new structure thus making my other patch(es) useless.
>
> To get all of this working is quite a bit of work and certainly by no means
> easy for me! But i like to do this so why not :) And i have some free time
> the coming weeks so right now is the best time to do this.
>
> I did do a bit of brainstorming in here while typing. I hope it's all clear.
> Please do give your opinion/input on how we should proceed with this.
>
> Cheers,
> Mark

It sounds like this is being limited to just mouse and keyboard
shortcuts.  Is there a reason this can't be made more general, so
other devices can provide shortcuts as well?  Currently we have a
variety of devices with their own unique button and action-handling
systems.  Being able to provide a plugin-based system that anyone can
write an additional backend for would allow us to unify these
interfaces.

-Todd