Re: about gtk/_gtk_kegtkkeyhash.c:y_hash_lookup() and fuzzy matches

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.


(*) 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]