ALT+<KEY> - BUG

[Timo Hartmann]

When I first used the new Krusader based on KDE4+QT4 I was very annoyed
that some of my most used shortcuts (ALT+O) did not work. Searching the
bug-database was no help, there was only the "solution" to use other
shortcuts (SHIFT+ALT+O).

After I used that for now some time I got annoyed enough to look into
the source-code of Krusader (and QT and KDE) to track the cause down.

First how to reproduce the bug:
1.) set the environment locale to english
(e.g. using bash type "export LANG=C.UTF-8")
2.) start krusader with this locale
3.) check via "configure shortcuts" that no other key is assignet
to ALT+O
4.) use ALT+O . The list of available media should open
(mediabutton.cpp)
5.) assign ALT+O via "configure shortcuts" to "sync panels"
6.) use ALT+O. nothing should happen besides "QAction::eventFilter:
Ambiguous shortcut overload: Alt+O"

Second the reason:
1.) the ultimate culprit is KAcceleratorManager
2.) this is invoked by KCheckAccelerators
3.) an instance of which is created by KApplicationPrivate
4.) which is owned by KApplication

KAcceleratorManager walks over all widgets and assigigns shortcuts to
them (ALT+O for "Open the available media list"). It does normally do so
every time the gui changes! (In my oppinion this whole thing is quite
sick...)

attention:
1.) The whole thing depends on your locale, because
KAcceleratorManager uses the titles of the widgets.
Depending on the language a whole range of keys can be affected.
So ALT+<some key> may work on one machine and fail
and some other.
2.) Besides ALT+O other keys may be affected

Third the solution
1.) the simplest:
Add
[Development]
AutoCheckAccelerators=false
AlwaysShowCheckAccelerators=false
to kdeglobals or krusaderrc. this shuts KCheckAccelerators down.
2.) the most sane:
Add "KAcceleratorManager::setNoAccel(this);" at
the beginning of KrusaderView::start(...)
3.) the brute force variant:
hack qt so that qt_set_sequence_auto_mnemonic is visible.
then call "qt_set_sequence_auto_mnemonic(false)" in
main.cpp this does away with all auto-assigned shortcuts
(and all others...) once and for all.

I personally prefer solution (2). I would appreciate if that would be
built into krusader. Or perhaps one should contact the kde-people and
convince them to optionally shut this
KAcceleratorManager/KCheckAccelerators down. At the moment I can't judge
if this KAcceleratorManager/KCheckAccelerators stuff is a bug or a feature.

Greetings
th

p.s.: Here is what I found in the bug-database related to this stuff:

http://sourceforge.net/tracker/index.php?func=detail&aid=2011438&group_id=6488&atid=106488
http://sourceforge.net/tracker/index.php?func=detail&aid=2564684&group_id=6488&atid=106488
http://sourceforge.net/tracker/index.php?func=detail&aid=1988885&group_id=6488&atid=106488
http://sourceforge.net/tracker/index.php?func=detail&aid=2053528&group_id=6488&atid=106488

All (and more) should be cured with my proposal...

[Václav Jůza]

Hi,

thanks for analysis.

I think that the auto-assigning the shortcuts to the controls (especially
menus) is useful since it allows all actions to be invoked from the keyboard
and I think it is also a part of some HIG guidelines. Disabling it at all just
in Krusader would mean that it will behave different than other KDE
applications.

The conflicts can be easily prevented by complying to some conventions, like:
1) Ctrl+Alt+<sometnihg> and Win+<something> global shortcuts assigned by the
window manager/operating system
2) Alt+<single key> - application shortcuts assigned by the toolkit/window
manager (Alt+F4 - close window, Alt+F - the File menu, etc.)
3) The rest, especially Ctrl+<something> - the application

I am not sure if these conventions are described somewhere, but most
applications accross environment comply to this.

But what I think it would be good, if the user defined shortcuts take
precedence over the automatically-assigned (i.e. if you assign Alt+O in
"configure shortcuts" it should not be auto-assigned to a menu item), but I do
not know how (and if) this could be done.

If this is not possible I would prefer to create an option in the Konfigurator
to enable/disable your solution 1) or 2).

Regards,
Vaclav

Dne úterý 24 Listopad 2009 Timo Hartmann napsal(a):

> --
>
> You received this message because you are subscribed to the Google Groups
> "krusader-devel" group. To post to this group, send email to
> krusade...@googlegroups.com. To unsubscribe from this group, send
> email to krusader-deve...@googlegroups.com. For more options,
> visit this group at http://groups.google.com/group/krusader-devel?hl=en.
>

[Jonas Bähr]

Hi,

In my eyes, disabling the automatic shortcut assignment for menu
entries (as I understand it, that's the issue) is something only power
users will do. So, perhaps it's enough to create a FAQ entry about
this hidden configuration option...

> 2.) the most sane:
> Add "KAcceleratorManager::setNoAccel(this);" at
> the beginning of KrusaderView::start(...)

... or add it to Konfigurator, making your solution 2 configurable via
the GUI.

> 3.) the brute force variant:
> hack qt so that qt_set_sequence_auto_mnemonic is visible.
> then call "qt_set_sequence_auto_mnemonic(false)" in
> main.cpp this does away with all auto-assigned shortcuts
> (and all others...) once and for all.
>
> I personally prefer solution (2). I would appreciate if that would be
> built into krusader. Or perhaps one should contact the kde-people and
> convince them to optionally shut this
> KAcceleratorManager/KCheckAccelerators down. At the moment I can't
> judge
> if this KAcceleratorManager/KCheckAccelerators stuff is a bug or a
> feature.

Feel free to start a discussion about it on kde-cor...@kde.org
(you'll get a notice that you message will be reviewed if you don't
have post rights yet, so do not wonder if it does not appear
instantaneously)

bye,
Jonas

>
> Greetings
> th
>
> p.s.: Here is what I found in the bug-database related to this stuff:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=2011438&group_id=6488&atid=106488
> http://sourceforge.net/tracker/index.php?func=detail&aid=2564684&group_id=6488&atid=106488
> http://sourceforge.net/tracker/index.php?func=detail&aid=1988885&group_id=6488&atid=106488
> http://sourceforge.net/tracker/index.php?func=detail&aid=2053528&group_id=6488&atid=106488
>
> All (and more) should be cured with my proposal...
>