Re: keycode handling

[Vlad Harchev <hvv hippo ru>]

On 3 Dec 2000, Havoc Pennington wrote:

> 
> Vlad Harchev <hvv hippo ru> writes: 
> > Solution:
> >  I propose to extend GdkEventKey even further, by addition of the following
> > members (sorry, stupid names - suggest a better ones):
> >  gint	keyval_g0; 
> >  gint 	keyval_g0_l0;
> > 
> 
> People can just call gdk_key_info_to_keyval () to get these values
> when appropriate.

 We can be nice and helpful by already providing that value. This way, every
signal handler won't waste time computing that value itself. And it will make
the hacker's work easier - the need to add a long construct with
invokations of gdk_key_info_to_keyval will be eliminated (and automatic
way of making apps i18n-input-friendly via tweaking with preprocessor macros
would be applicable).
 
> We should go ahead and make GtkAccelGroup GtkBindingSet etc. use them.

 That's definitely needed.
 
> It isn't right to use them outside of accelerators though, so you
> can't just swap them in to apps in all cases.

 I think swapping fields is innocent thing. All textedit-like widgets (that
need precise key pressed to insert something into buffer) use 
GdkEvenKey->string. All other correct ways of use of 'keyval' is for hardcoded
accelerators, so it should be IMO safe to swap fields to make apps
i18n-friendly.

> Conceivably we should have an abstraction:
> 
>  guint gdk_keycode_get_key_cap (guint keycode);
> 
> which returns the "accelerator key" for the key code.

 That would be handy. But IMO its return value should be already stored in
GdkEventKey.

> Note that I did something different for Ctrl-Shift-hexdigit: I first
> see if the keyval in the current group/level is a hexdigit, and use it
> if so, otherwise I scan the list of keysyms for the pressed key code,
> and if any of them are hexdigits I use that hexdigit. So this is
> fallback to any group/level that happens to have the digits, not just
> 0/0.
> 
> Havoc
> 

 Best regards,
  -Vlad