GNOME Bugzilla – Bug 104112
Disassociation of Keystroke from Menu Underline
Last modified: 2018-05-02 13:46:58 UTC
gtk_label_set_uline_text_internal interprets "_" to underline the following character and map the character to a keystroke following Alt. For example "_File" will display in a menu with "F" underlined and mapped to the key sequence Alt+[Ff]. This patch adds support such that if a 2nd "_" is found it is applied to the key strokes and is not displayed. The benefit is that a non-Roman character can be underlined in a menu while a keystroke mapping remains Roman for the most typical keyboards. This gives GUIs a more natural look and no Roman character need be added. The popular solution for this issue now is to add the key stroke as per "xyz (_F)" following the non-Roman text "xyz". The consequence here is an extra 4 characters of width foreach menu root item. Hence this patch would allow definitions like "_xyz_f" where the "x" character (non-Roman) is underlined in display and Alt+[Ff] is the keyboard shortcut. A lingering issue is that for input methods that ARE case sensitive (such as Ethiopic) this patch is only a partial solution. Some solution is needed here to make the key accelerator mappings case aware.
Created attachment 13739 [details] [review] gtk+2.2.0 patch for menu-keymap problem
[ Note, patches should be made using 'diff -u' as mentioned in the README. A diff as attached here can't really be applied except manually, with a lot of effort ] Hmm, I could see where this could be useful, though this has the disadvantage that it requires the translation to be tied to a particular input method. I don't think the particular syntax is right; maybe something like: \[_f\]_xyz Where the \[\] would signal not to output the characters inbetween but to scan them for underline characters. Pango would need the corresponding change, because it handles the underline parsing when label "markup" is in use. The case sensitivity issue shouldn't matter... if there is a collision, GTK+ will consider _f and _F to be distinct.
> I don't think the particular syntax is right; maybe something > like: I'm certainly not married to the syntax. The only thought I had behind reusing "_" was to keep the meta characters that have to interpretted (and escaped) to a minimum. In a discussion in December(?) Pablo Saratxaga suggested something of the form "_xyz|f" which seems pretty easy on the eyes.
I'm afraid this is not really input method's issue, but an enhancement of key accerarator. I'm moving this to 'gtk' and reassign. Is a separate bugzilla for pango change - then we'll need it to put as a dependency.
Created attachment 56247 [details] [review] GTK+ patch
Created attachment 56248 [details] [review] Pango patch
Here are patches which implement the following syntax: f_oo : accel key o, o underlined f_[p]oo : accel key f, o underlined [x] will only be recognized if it immediately follows an _ and has exactly one character between [ and ]. That still allows for "_[ bracket" to give an underlined [.
souds good! > f_oo : accel key o, o underlined > f_[p]oo : accel key f, o underlined ^ I think here you mean "accel key is p, ..."
Matthias, I'm a bit worried about the Pango patch since it may access beyond the end of the string. Checking for '[' as early as possible and checking the end of string will fix that.
Yes, however, the patch needs more work anyway, since I need to think through the keymap-dependency issue.
If pango is getting involved, would it be possible for the "x" (of [x] or old style _x) to be an arbitrary Unicode letter? This would be helpful for syllabaries where up to 13 letters may start with the same keystroke (ፈ => "fe", ፉ => "fu", ፊ => "fi" ... ). So the unicode aware Alt+ trigger would act on the composed letter and not depend on the underlieing keyboard. This was an actual problem that had to be worked around in the am-ET translations.
Accelerators and mnemonics are traditionally distinct from input methods on all platforms, and I don't think it would work very well to combine them; GTK+ should be happy with _ፈ, but you can't type that unless your keyboard map has a ፈ key. This is in fact why for Asian locales you have the [Chinese for file] (_F) convention.
Several interesting ideas related to this patch came up in the thread started here: http://mail.gnome.org/archives/gnome-i18n/2005-December/msg00091.html 1) avoid a keymap dependency by allowing multiple accelerators to be specified gl_[üu]ücklich to allow both ü (if available in the keymap) and u to work as accel keys, with ü being underlined 2) when faced with gl_ücklich, consult the compose table in gtkimcontextsimple to find out that ü can be constructed by Compose + u + <accent>, and deduce that u is also a valid accelerator Needs some research to see which of these ideas is workable
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/224.