Standard shortcuts KCM

[Michael Jansen]

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. 

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.

> > Another question is wether to warn the user when doing changes of these
> > possible conflicts and that the changes will only get active after an
> > restart of an application.
>
> A ++ from me because it's easy to shoot yourself in the foot there.

I will put that on my todo list.

> > Mike
>
> 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" :-) 


-- 
Michael Jansen

http://www.michael-jansen.biz