279163 - "Select all" on Linux should show the actually used (dynamic) key binding, not always Alt+A

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Robert Kaiser]

Hen I asked aaronlev on IRC about
https://bugzilla.mozilla.org/show_bug.cgi?id=239040#c1
this is what the discussion brought up:

<Neil> aaronlev: it's specific to select all - ctrl+a is an emacs key
<KaiRo> Neil: I don't have gnome prefs, as I'm using KDE and only have installed
the bare libs that some apps need of gnome
<aaronlev> oh ok
<aaronlev> i can't ever remember the screwed up key assignments on linux
<KaiRo> Neil: but we don't act on Alt+A anyways, even though we show it in the UI...
<KaiRo> aaronlev, Neil: actually, it seems to be only an inconsitency of what we
do vs. what we show in the UI (all over the components of SeaMonkey though)
<Neil> KaiRo: the UI doesn't reflect bryner's dynamic bindings
<Neil> KaiRo: so you're picking up non-emacs bindings, although the UI still
assumes emacs bindings
<KaiRo> we're acting on Ctrl+A for various "Select all" but show "Alt+A" -
that's bad habit...
<KaiRo> Neil: oh... the interesting thing is we show Ctrl for all other
keybindings, just not for "Select all"
<Neil> KaiRo: well, our other bindings were chosen not to conflict with emacs keys
<Neil> KaiRo: except we got it wrong for check spelling :-(
<KaiRo> Neil: ah, ok... it's still strange though and it gets users confused...


So if I got everything correctly, the basic thing here is that we dynamically
select the key binding as Alt+A or Strg+A, but always show "Alt+A" in the UI.
We should show the really used key binding in the UI though.

(bryner, I was told the dynamic stuff is what you created, please move the bug
to the component it should belong to, I couldn't figure it out correctly)

Comment 1

[Andrew Schultz]

I'm guessing we'll automagically get this right when we switch to toolkit.

Comment 2

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 3

[Robert Kaiser]

We're running into a conflict there as Alt+A opens the "Ansicht" ("View") menu on German versions. I think we should at least display only the Ctrl+A variant.

Comment 4

[Robert Kaiser]

Neil, what do you think on that?

Comment 5

[[e-mail]]

Linux allows me to turn off the Ctrl+A variant, but Alt+A always works...

Comment 6

[Robert Kaiser]

No, it doesn't always work, it actually never works in the German version, where it's bound to the "Ansicht" ("View") menu, which has the "A" accesskey in all applications across all platforms.

Comment 7

[rsx11m]

This obviously has been there for quite a while already, but I've just noticed today that Linux and Windows versions show me different keyboard shortcuts in the menus, then finding this bug here before filing my own.

Indeed Alt+A and Ctrl+A select the entire content in a browser window, whereas there is a different behavior in Mail & Newsgroups. Actually, bug 164362 still applies (at least on 2.0 I've tested with ad-hoc) and Alt+A shows me the full Search dialog per accesskey definition, whereas Ctrl+A selects all messages in the list as desired.

So, why isn't it possible to just change "alt" to "accel" in line #35
of suite/common/unix/platformCommunicatorOverlay.xul, currently
> <key id="key_selectAll" key="&selectAllCmd.key;" modifiers="alt"/>
which should make it consistently Ctrl+A for all "Select All"?

That's what Thunderbird has done in bug 536346.

Comment 8

[rsx11m]

Never mind, guess I was thinking too simple. I've made the suggested change in suite/common/unix/platformCommunicatorOverlay.xul on trunk, but all it does is to flip the "Alt+A" label to "Ctrl+A"; it still appears that both Alt+A and Ctrl+A can be used for "Select All", indistinguishable unless it's overridden
by an access key as for the advanced search in Mail & Newsgroups.

Speaking of which, there is a key_selectThread in platformMailnewsOverlay.xul, where changing it stubbornly doesn't affect the Edit > Select > Thread shortcut Alt+Shift+A shown in the menu. So, that would be another thing to sort out.

Well, it was worth a quick try.  ;-)