On Sun, Jan 08, 2017 at 11:13:52AM -0700, Jaimos Skriletz wrote:
> On Sun, Jan 8, 2017 at 3:14 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> > On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote:
> >> Here is an old (minor) bug that is lurking in the Debian BTS.
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363
> >>
> >> The bug is that when assigning non ASCII keys as hot keys in a Menu,
> >> the underline underlines the non ASCII character and the one after it.
> >
> > Hotkeys must be printable 7 bit Ascii characters, which is
> > probably not documented. The reason for this is that the hotkey
> > is specified as a substring from the item label (e.g. "á") instead
> > of a key name ("aacute"). X has no real way to convert a string
> > into a key name or vice versa, so hotkeys work only for keys where
> > both representations are the same.
> >
>
> If keybindings for non 7 bit ASCII keys don't work, documentation
> could be useful. Though this has been around for a long time and not
> many seem to mention it so it probably isn't a big deal in the overall
> picture.
This may be a real issue for automatic hotkeys in languages other
than English. Words beginning with non-latin letters like Ü, Á
etc. are not uncommon in European languages.
> > I can reproduce the drawing bug. Maybe we should simply disable
> > hotkeys completely for anything not 7 bit ASCII.
> >
>
> Disabling the keys since they aren't working anyways and giving a
> warning may be useful for those who try to use non ASCII characters.
> Such a warning should only trigger when items are added to the menu,
> not each time the menu pops up.
Yes, a warning if it's a manual hotkey, at least. Not sure what
to do about automatic ones. It may be confusing to get no hotkey
without a warning (and without iconv we can't reliably look past
the first letter). On the other hand the user has probably not
asked for warnings regarding automatic hotkeys.
> At least this way if anyone tries to use non-ASCII characters they are
> correctly informed that they do not work and this can move to a
> feature request to add support for these keys.
I *could* implement the table I mentioned (there are several
version floating around the net) to get non-Ascii hotkeys working,
but then we might as well leave hotkeys as they are in fvwm-2.x
and rewrite the hotkey syntax to allow specifying key names for
fvwm-3.x. E.g. "&(aacute)" or something like that, or even
ábc use "á" as hotkey if iconv support is compiled in
(using a built-in table), otherwise no automatic
hotkey. Maybe rather use b as the hotkey as there's
no guarantee the keyboard has a key for á?
&ábc if iconv support is compiled in; automatic hotkeys
work; use built-in table
&(aacute) string representation of a keysym (XStringToKeysym)
&(12345) numeric representation of a keysym
Too stupid that X has no way to convert keysyms into printable
strings and vice versa.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
