KAction and KShortcut in frameworks

[Mark]

On Fri, May 11, 2012 at 8:42 PM, David Faure <faure at kde.org> wrote:

> On Friday 11 May 2012 19:57:11 Mark wrote:
> > >  KShortcutManager::setDefaultShortcut(newAct, Qt::Key_F6);
> >
> > I like this idea!
>
> Good, me too :-)
>
> > I was actually intending to use the Shortcut Editor but i
> > didn't look into specifics yet.
> >
> > With dynamic property you're talking about
> > http://qt-project.org/doc/qt-4.8/qobject.html#setProperty right?
>
> Yes. Just like the current KAction code already does, to store the default
> primary and alternate shortcuts.
>

Ah, oke.

>
> > > krazy would basically flag any direct call to QAction::setShortcut as a
> > > "bad
> > > hardcoded shortcut, you should use KShortcutManager instead".
> >
> > What you're suggestion is that _all_ KAction obects go through
> > KShortcutManager.
>
> All those with a default shortcut set by the application, yes, obviously.
>
> > Might be good for an ideal world situation but i don't
> > really know if this is desirable. I just don't know for this part.
>
> Why not? How else would this work? I'm not sure what the reservation is,
> here.
>
> The alternative is hardcoding shortcuts that the user cannot modify, I
> don't
> see why we would want to do that.
>

The only reservation i have is the case where some developer comes by and
makes a KDE application with actions that aren't defined yet in Shortcut
Manager. Then that developer might just wnat to use setShortcut which is
fine right? Yet krazy is going to blame the developer that he shouldn't do
that. That's my only reservation. If that is a non issue then i have no
reservation ^_^

>
> > I do want to get back on KInputShortcut and KInputSequence about them
> being
> > not KDE specific and should end up in Qt. I fully agree and there has
> been
> > discussion about that some time ago on the Qt mailing lists. I actually
> > started that discussion so i know what i'm talking about :)
>
> Ah, great. Sorry for my bad memory ;)


> > The idea back
> > then was that global shortcuts should use the platform plugin stuff and
> > should use some kind of global shortcut storage mechanism. The thing
> that's
> > called "Shortcut Editor" in KDE. Mac and Windows sadly don't have such
> > applications. So the Qt implementation would be quite... difficult. KDE
> > already has some more infrastructure with global shortcuts so there it's
> > "fairly easy" to get the suggested approach working.
>
> I'm not talking about global shortcuts, but about input shortcuts (i.e.
> including gestures and mouse+keyboard combinations in there).
> Isn't that the idea of KInputShortcut?
>

Oke, i'm over eager again ;)
Lets - for the sake of simplicity - ignore global shortcuts for now.

>
> I'm leaving global shortcuts completely on the side, they are a whole other
> can of worms. One step at a time :-)
>

Deal

>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>
>
Another question since we seem to be on the "we both agree" track here. How
about the current KShortcut and KAction stuff along with deprecation. What
should be deprecated, Where should it be deprecated (in 4.9 is my
preference) and how about my current patch in reviewboard? Is that one
becoming obsolete with this idea? (seems like it)

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120511/1ecc2e3d/attachment-0001.html>