[Geany-devel] Unicode code entry

Lex Trotman elextr at xxxxx
Mon Sep 28 03:41:10 UTC 2009


2009/9/28 Enrico Tröger <enrico.troeger at uvena.de>:
> On Fri, 25 Sep 2009 11:12:07 +1000, Lex wrote:
>
>>2009/9/25 Enrico Tröger <enrico.troeger at uvena.de>:
>>> On Wed, 23 Sep 2009 09:35:32 +1000, Lex wrote:
>>>
>>>>Hi,
>>>>
>>>>I am having difficulty with Unicode code point insertion.  Basically
>>>>it doesn't work and I can't see how it could as described in the
>>>>manual.
>>>>
>>>>I have control-Shift-u undefined, but since on_key_press_event
>>>>catches keybindings before they get to GTK, all control-shift
>>>>keybindings for hex characters (a-f)  must be undefined.  This means
>>>>many of the find
>>>
>>> Ouch.
>>> I guess I never noticed it as I use always Ctrl-Shift-Alt-u for some
>>> reason, not sure whether it worked only this way long time or whether
>>> it is because I could never remember the exact key combo and so just
>>> pressed all :).
>>
>>Perfectly reasonable, but unfortunately that doesn't work for me
>>either :-(
>>
>>> Regarding a solution, two things come to my mind:
>>> a) we add some more super magic to the keypress handler function
>>> trying to detect if the user is currently at inserting an unicode
>>> sequence and then ignore other keybindings until finished
>>> b) we mention in the manual that Ctrl-Shift-Alt is preferred as it
>>> prevents unintentional triggering of defined shortcuts
>>>
>>> But well, b) is only of limit use as it still would trigger shortcuts
>>> defined as Ctrl-Shift-Alt-[a-f].
>>> a) might be a solution but has some potential to get quite hacky.
>>>
>>> Does anyone has an idea for a solution c)?  :)
>>>
>>>
>>>>keybindings must be undefined. But even then, with control-shift held
>>>>digits are seen as !@#$%^&*() and rejected.
>>>
>>> Can't reproduce this here, even with Ctrl-Shift pressed, digits are
>>> still digits.
>>>
>>
>>Hmmm, weirder & weirder I uncommented the geany debug in
>>key_press_event & typed into an empty document (not entering Unicode,
>>just typing) got the following, # comments are mine
>>
>>** INFO: 65507 (65507) 0 (16)     # Press & hold Ctrl
>>** INFO: 65505 (65505) 4 (20)     # Press & hold shift
>>** INFO: 33 (33) 5 (21)                 # Press 1 keycode 33 is !
>>state 5 is Ctrl&Shift shows as !
>>** INFO: 64 (64) 5 (21)                 # Press 2 keycode 64 is @
>>state 5 is Ctrl&Shift but does not show anything !!!!!!!!!!
>>** INFO: 35 (35) 5 (21)                 # Press 3 keycode 35 is #
>>state 5 is Ctrl&Shift shows #
>>** INFO: 36 (36) 5 (21)                 # Press 4 keycode 36 is $
>>state 5 is Ctrl&Shift shows $
>>** INFO: 37 (37) 5 (21)                 # Press 5 keycode 37 is %
>>state 5 is Ctrl&Shift shows %
>>** INFO: 94 (94) 5 (21)                 # Press 6 keycode 94 is ^
>>state 5 is Ctrl&Shift but does not show anything !!!!!!!!!!!!!!!
>>** INFO: 38 (38) 5 (21)                 # Press 7 keycode 38 is &
>>state 5 is Ctrl&Shift  shows &
>>** INFO: 42 (42) 5 (21)                 # Press 8 keycode 42 is *
>>state 5 is Ctrl&Shift  shows *
>>** INFO: 40 (40) 5 (21)                 # Press 9 keycode 40 is (
>>state 5 is Ctrl&Shift shows (
>>** INFO: 41 (41) 5 (21)                 # Press 0 keycode 41 is )
>>state 5 is Ctrl&Shift shows )
>>*
>>
>>So there is no way that they could be interpreted as digits, they are
>>all punctuation keycodes???  Could the difference be due to different
>>keyboard maps because you have a European keyboard and I have a US
>>ASCII keyboard?? And why arn't @ and ^ inserted into the file??
>
> The above list is the same as I get on my system, so far so good.
> E.g. if I press Ctrl-Shift-5 I get the same as you, keycode 37 and
> state 21, cleaned 5.
> The difference is that if I press Ctrl-Shift-u before and then pressing
> 5 while holding Ctrl-Shift I still get keycode 37 but it is inserted as
> 5 as part of the Unicode string.
> So, apart from the triggering of other keybindings, this is what I'd
> expect.
> Can you confirm this behaviour so far?
>

The problem is on a machine (hearinafter known as machine 1) running
Gnome + GTK+2.12.9 ctrl-shift-u nothing is displayed then 5 while
holding the ctrl-shift gives %, this was with Geany 0.18 and head

Tried it on a machine (hearinafter known as machine 2) with Xfce +
GTK+2.12.9 and it works, ctrl-shift-u gives an underlined u and
ctrl-shift 5 an underlined 5 etc until a non-ctrl-shift character when
it enters the unicode character this was with Geany r3994 (pre 0.18 I
think)

That seems to indicate that:

1. it isn't a Geany problem
2. it isn't a GTK problem
3. it *is* a Gnome problem, but how Gnome interferes I don't understand

But !!! Having written that I've read a little used piece of GTK doc,
IMContexts.  This defines how input methods work. For an entry widget
the context menu gives you a choice of input methods.

Using the find entry on the toolbar as an example I found that machine
1 has the input method set to X input method and machine 2 has it set
to default.

Setting machine 1 to default makes it work like machine 2, that is
unicode entry works in the entry widget as described.

Unfortunately there is no way of setting the input method for the
editor window that I could find. Any ideas?

Cheers
Lex

>
>>PS Found a workaround for entering Unicode using the Gnome character
>>map, but its very invasive.
>
> Yeah, I don't see this as any alternative, not even a workaround.

True, but at least I could enter characters into the test file so I
could go on testing my code.

>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>



More information about the Devel mailing list