Standard shortcuts KCM

[Andreas Hartmetz]

On Saturday 12 July 2008 19:54:44 Michael Jansen wrote:
> On Friday 11 July 2008 13:59:04 Andreas Hartmetz wrote:
> > On Thursday 10 July 2008 22:05:53 Michael Jansen wrote:
> > > Hi
> > >
> > > i just commited the new standard shortcuts KCM. It is now again
> > > possible to configure shortcuts like Cut/Copy/Paste ... for all
> > > applications at once.
> > >
> > > There is a danger in that. It's very easy to produce shortcut conflicts
> > > with that kcm. When changing a default shortcut in this kcm it is
> > > impossible to check if there is any application out there using this
> > > shortcut.
> > >
> > > When such an application with a conflicting shortcut starts next time
> > > nothing happens. When this conflicting shortcut is triggered nothing
> > > happens either. We only have conflict checking on shortcut
> > > configuration, and qt has a feature that conflicting shortcut do not
> > > trigger the activated() signal but the activatedAmbiguously() signal.
> > > That could be frustrating for a user. I will try to come up with a
> > > solution informing the user when using such an ambigous shortcut using
> > > that signal but we will see if it is doable.
> >
> > It's the only thing I can think of - emit a warning on
> > activatedAmbiguously(). Where would you want to connect to the signal?
> > There can, at least in theory, be QActions that are not KActions.
>
> I have no idea yet. Just found that signal and had no time to investigate
> further.
>
> > Finally, those are broad statements and some standard shortcuts are
> > likely to be useless. In fact I saw thome that made me go "huh?". There
> > is no reason to keep them except...
> > This might not be possible due to binary compatibility because there are
> > some getter methods for certain (all?) standard shortcuts. You could
> > return nothing, maybe.
>
> Not all of them have getter methods. All i added do not have one and the
> getter methods weren't complete to start with. David said - and i agree -
> we should deprecate the getter methods. They only clutter the api. At least
> for StandardActions. I personally see no need for
> KStandardShortcut::reload() either.
> KStandardShortcut::shortcut(KStandardShortcut::Reload) is just fine for me.
>
I agree that getter methods are not especially useful. And IMHO short API 
documentation is good API documentation so the methods are clutter from that 
POV.

> The main question to answer is if standard action automatically means
> standard shortcut. And if not how to determine which standard actions
> deserve a standard shortcut.
>
> So what's the purpose of Standard Actions. Easier setup? Consistent
> wording? Consistent shortcuts? The latter would imply that each standard
> action should have a standard shortcut associated.
>
Consistent shortcuts seem to be the most important thing to me, by far.
I also think that each standard action should have a standard shortcut where 
it makes sense, and those should be most cases.

> >
> > Something different just occurred to me: What about a krazy check for
> > applications assigning standard shortcuts to some other action? I pressed
> > Ctrl-F in KMail to see if the editor would go fullscreen (silly, I know).
> > Instead a search popup appeared. If and when we have time for such tiny
> > issues (real soon now :) ) this could be a nice addition to our automatic
> > QA.
>
> FullScreen is CTRL-SHIFT F if i understand that correctly. But it doesn't
> work either. The other problem with the standard shortcuts is: "they have
> to be used to be active" :-)

People, you've heard it. Right? :)

-- 
I'm really excited now, and ready to hit that vast asphalt ribbon of 
adventure!