Standard shortcuts KCM

[Andreas Hartmetz]

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.
In my not-so-humble opinion changing standard shortcuts is a fringe feature 
which is OK as long as it doesn't cause problems if you decide not to use it. 
If somebody wants to use it, fine. Do it at your own risk.

> Because of that we probably want to keep the number of kde wide standard
> shortcuts down.
>
Please take a step back for a moment and look at the priorities:
-Changing standard shortcuts: rarely used (contradictions to this thread
 please), usefulness doubtful. KDE is not some other DE and it won't make
 users of other DEs feel at home by imitating their shortcuts while certain  
 others break (see above).
 The need for this feature could be further reduced by coordination with
 Gnome so we both have the same standards. This makes sense because people
 *will* run KDE and Gnome apps at the same time.
-Having uniform shortcuts for many things: Saves users time, makes them feel
 at home: "I know how to make any program full-screen". Not as valid for
 very uncommon "standard" shortcuts if there are any, sure.

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.

Another consideration is to keep library complexity reasonably low if there is 
no pressing need to increase it. If a solution to this not-really-problem 
requires a lot of effort it's not worth it IMHO.

> If a shortcuts is a standard shortcut and configurable is determined by
> kdelibs/kdeui/actions/kstandardaction_p.h . If idAccel there is not
> KStandardShortcut::AccelNone the actions shortcut is configurable by the
> new kcm.
>
> Now the question is where to draw the line. Currently i only left out the
> "About XYZ" Action because it seems to be silly and the "Open Recent"
> standard action because it is no action in the strict sense. It is a
> submenu and triggering it wil have no effect.
>
> So discussion is open to all interested people which action to further
> exclude.
>
> 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.

> 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.

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