Different "strategy" for global shortcuts

[Mark]

On Tue, May 29, 2012 at 9:55 AM, Mark <markg85 at gmail.com> wrote:

> The following was a conversation between David and me. Sending it to the
> list since it belongs there.
>
> On Monday 28 May 2012 17:43:47 Mark wrote:
> > Hi David,
> >
> > I've been thinking a bit more about KAction to figure out a way to get
> rid
> > of it completely (along with KShortcut). I think i found that solution.
>
> OK. Not sure why you're emailing in private rather on k-f-d though...
>
> > For starters, the setDefaults/restoreDefaults has to go in QAction. I
> > mailed Rick about this to see if such a patch for Qt would be accepted.
>
> The naming would be setDefaultShortcut() or setDefaultShortcuts(), surely
> :)
> If it doesn't say "shortcuts" it gets confusing...


Obviously. Proposing the following additions to QAction:
- setDefaultShortcuts
- defaultShortcuts
- resetDefaultShortcuts
- setHelpText (convenient function that
sets: setToolTip, setStatusTip and setWhatsThis in one go)

- signal: defaultShortcutsRestored (emitted when resetDefaultShortcuts is
called)


>
> > Lets for the sake of this mail assume that it does get accepted and ends
> up
> > in Qt 5.1.
>
> OK.
>
> > Then all that's left in KAction is global shortcuts.
>
> Well there's actually more stuff (like gesture support, but it seems this
> was
> never finished, so we could indeed kill that and wait for it to be in Qt).
> There's KAuth support, not idea how this works or how it could be done
> differently.


Somehow this smells a little wrong. What does KAuth have to do with a
QAction element..
Perhaps KAuth should react on registered shortcuts outside of the QAction
(KAction) class. Just "thinking out loud" now.

>
>
> We should submit setHelpText() to QAction for convenience.


See above.

>
>
> > So why do we even have global shortcuts in there? Can't we just use
> > shortcut editor as "register" for global shortcuts?
>
> The editor isn't always running ;)


You get the point ;)

>
>
> > That probably means that you get a global sortcut registration function
> in
> > code. So something like this:
> > KSomething::registerGlobalShortcut("name", shortcut); <-- is obviously
> > wrong but you get the idea.
>
> Yeah, this seems to be the obvious way to move the functionality out of
> KAction. Feel free to work on a proof of concept in the frameworks branch,
> the
> only way to see if this would work out, is to try it, IMHO.


Awesome. Though not going to start on this one yet. First the tooltip stuff
(other discussion in plasma-devel) before i start on something else.

>
>
> >  (KConfig? KGlobal? K..?)
>
> Not those, for sure. KConfig doesn't know QtWidgets, KGlobal is on the way
> out.
> This should be a new namespace or class, for modularity. Something like
> KGlobalShortcutRegister or what not. Or maybe new code in the existing
> KGlobalAccel.
> Problems to solve will include storing data for each action (I'd recommend
> dynamic properties for this too), and ensuring that changing the default
> shortcut as a user, updates the global shortcut.


Note: this is why i added the above defaultShortcutsRestored signal to
allow a signal/slot connection when the shortcuts are restored and thus
update that in the registered shortcuts. Wherever that might be. I like you
suggestion here! I'm not quite sure if this should go in a new global class
or added to an existing one. In the docs i also found "KGlobalShortcutInfo"
... what is that one doing anyway? (no documentation)
http://api.kde.org/4.8-api/kdelibs-apidocs/kdeui/html/classKGlobalShortcutInfo.html
From
the looks of it, it "seems" to be what is suggested here.. It is being used
in just a few places: http://lxr.kde.org/ident?i=KGlobalShortcutInfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120529/f45852b3/attachment.html>