[text] Don't interpret the unicode value when the control modifier is on

When a letter key is pressed with the control key held down one of
three things will happen :-

a) If the stage is embedded within a GtkClutterEmbed the unicode value
   will be filled from gdk_keyval_to_unicode. This will be the same
   value as if control was not pressed (so Ctrl+V will be 'v').

b) If the stage is not in a GtkClutterEmbed and Clutter is running on
   the X11 backend then it will try to fill in the unicode value from
   XLookupString. This *will* take into account the control so the
   unicode value will represent a control character (Ctrl+V will be
   '\x16').

c) Most other backends will not bother to fill in the unicode
   value. Therefore clutter_keysym_to_unicode will be used which also
   does not take into account the control key (so Ctrl+V will be 'v').

For cut and paste to work in Nbtk, the control keys need to bubble up
to the parent NbtkEntry container. This works fine for 'b' but not 'a'
and 'c'.

This patch makes ClutterText always allow the event to bubble if the
key is not handled by the binding pool and the control modifier is
down.

Ideally ClutterText would always get a unicode value that takes into
account the modifiers but this is probably best left up to the input
methods.

Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
This commit is contained in:
Neil Roberts 2009-08-17 17:43:42 +01:00 committed by Emmanuele Bassi
parent 5d7c2e7c44
commit 99437c4761

View File

@ -1312,7 +1312,8 @@ clutter_text_key_press (ClutterActor *actor,
*/
if (res)
return TRUE;
else
/* Skip keys when control is pressed */
else if ((event->modifier_state & CLUTTER_CONTROL_MASK) == 0)
{
gunichar key_unichar;