On Thu, 2006-08-17 at 13:58 +0200, didier . wrote:
> Hi
>
> On 8/17/06, Owen Taylor <otaylor redhat com> wrote:
>
> > It really needs to work both ways ... for non-latin accelerators when
> > the keyboard is in a latin layout as well as vice versa.
> >
> Yep
> >
> > (Plus you need gdk_keyval_to_unicode() and a real script check ...)
> Don't see how it will solve it.
I was referring to the > 0x7f check you had for "non-latin".
> As a matter of fact you can also get a
> 'puzzling' binding when combining a Latin and a non Latin layouts,
> with punctuation keys.
I don't think there would be anything particularly puzzling - if people
are used to the layout independence for letters, they wouldn't be that
surprised that it happened for punctuation as well.
In some cases it might even be appreciated. Imagine, hypothetically:
Latin: Backslash is an unmodified key
Cyrllic: Backslash is on ISO-level-3 + Other key
The user probably doesn't even *know* that they have a backslash in
Cyrillic mode, and if they've trained themself to a Control-\
accelerator would expect it to be in the same place independent of
keymap. (*)
This is different from:
- Someone who is switching layouts depending on whether they are
writing code or doing word processing.
- Someone who configured dvorak because it looked cool in the
capplet but never uses it.
However, certainly accelerators on keys not in the current group at
all is certainly a bigger issue.
> In my understanding this bug is triggered if:
> 1) A keyval is shared between layouts.
> and
> 2) A widget in the stack has only a binding for one of the keycodes involved.
>
> For testing purpose I've added a call to
> gdk_keymap_get_entries_for_keyval() after if (!have_exact) and checked
> the number of entries, it seems to work in all cases (french/english ,
> cyrillic/french with ascii or cyrillic accelerator, X latin keyboard
> or cyrillic keyboard at startup and so on).
That sounds like a plausible approach; as discussed above I don't think
it's quite perfect for punctuation, but it may be good enough. If you
attach a patch and a description of the approach to the relevant
bugzilla bug, I think some people who actually use non-latin layouts
are Cc'ed and will be able to comment.
I would suggest that you check for an entry in the current group rather
than n_entries > 1.
Owen
(*) Note that you can't turn this around and say that they would be
surprised by Control+Other Key working as an accelerator because
we don't do fuzzy matches on level, just on group.
Attachment:
signature.asc
Description: This is a digitally signed message part