Bug#45945: menu and widget hotkey conflict resolution

[Lubos Lunak]

On Wednesday 31 July 2002 09:20, Thomas Diehl wrote:
> Am Dienstag, 30. Juli 2002 21:39 schrieb Otto Bruggeman:
> > On Tue, 30 Jul 2002, Waldo Bastian wrote:
> > > On Tuesday 30 July 2002 04:01 am, ramon.casha at linux.org.mt wrote:
> > > > Package: kde
> > > > Version: KDE 3.0.2
> > > > Severity: wishlist
> > > > Installed from:    Mandrake RPMs
> > > > Compiler:          Not Specified
> > > > OS:                Linux
> > > > OS/Compiler notes: Not Specified
> > > >
> > > > A common problem, especially with translated applications, is that
> > > > it's easy for two menuitems or two widgets to end up with the same
> > > > "hotkey" (alt+letter). When this happens in KDE, one can get
> > > > undesired results. It's very difficult to visually check that every
> > > > widget/menu has a different hotkey, especially when menuitems are
> > > > added/removed dynamically based on the context.
> > > >
> > > > This issue could be resolved if KDE ran some kind of check when a
> > > > menu/dialog is displayed, checking for duplicate hotkeys, and
> > > > removing the second instance if found. By outputing a message to
> > > > stderr for each instance, it could also become easier for
> > > > translators/developers to find and fix them.
> > >
> > > We have such a check already, unfortunately I have no idea how it
> > > works.
> > >
> > > Cheers,
> > > Waldo
> >
> > Add this to $KDEHOME/share/config/kdeglobals:
> > [Development]
> > CheckAccelerators=F12
> >
> > You can choose your own key to activate the check for duplicate
> > accelerators. Unfortunately it does not suggest available accelerators
> > yet.
>
> This is exactly the problem. Apart from the fact that many translation
> teams are not aware of this mechanism (although it is described in the
> HOWTO) it is too much work to do this via try+error (press F12, get list of
> conflicts, use other hotkeys, recompile, press F12, find that you caused
> new conflicts, try other hotkeys, recompile, press F12, find more conflicts
> ...). Apart from the fact that it is almost impossible to cover all
> possible cases of dynamic KPart menus, changing control modules etc.
>

 Please try the attached kdelibs/kdecore patch (Miracles immediately, 
impossible within three days. Please allow eternity for packaging and 
shipping.). I'll let the massive propagation campaign to make translation  
teams aware of the feature up to you ;-p.

 The patch looks bigger than it is, because I got bored messing with large 
kapplication.cpp and moved the accelerators code to a separate file (when I'm 
in a mood to play with large .cpp files, I go hacking KWin). It should do 
everything you asked for, it can't make coffee yet though :). See top of 
kcheckaccelerators.cpp for instructions. If translators turn on the automatic 
checking, I'm quite sure they'll quickly either fix all the conflicts or turn 
it back off.

 I also fixed some details, like it didn't report menubar vs controls clashes, 
and I removed the strict menu checking option, because it was standing in the 
way, and I didn't find it useful in any way. If somebody knows how can be 
useful if it reports conflicts for

 ... &Help       (=menubar or popup menu)
      |
       -- &Help on XYZ  (=submenu)

 (which is what it did as far as I can say), complain, and I'll try to put it 
back.

> Most teams have to do their translations as last minute jobs before
> releases. Context checks are often very superficial, hotkey checks rarely

 No wonder, when those lousy developers love so much to change the strings one 
day after some poor developer finished translating them ;).

> happen at all. In fact, I don't know of one single team that really sorted
> this out. I'd say there are tons of hotkey conflicts in all translations.

 Maybe more. With automatic checking on, I see the dialog all the time :(. And 
as I actually don't have kde-i18n-cs for HEAD, it's not a translation but the 
strings written in the apps.


 BTW, I've also noticed kdelibs/kdeui/kaccelgen.h . It doesn't seem to be used 
much though.

-- 
 Lubos Lunak
 l.lunak at email.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcheckaccelerators.tar.bz2
Type: application/x-tbz
Size: 6891 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020731/504cbb91/attachment.bin>