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 keybindings must be undefined. But even then, with control-shift held digits are seen as !@#$%^&*() and rejected.
Am I doing something wrong or has the behaviour changed?
Using SVN head or 0.18 and GTK 2.12.
Cheers Lex
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 :). 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.
Am I doing something wrong or has the behaviour changed?
Not sure. I could imagine this has happened since the beginning but just nobody noticed it. At least I usually test this just with digits though I probably will change my behaviour in testing now that you mentioned it :).
Regards, Enrico
2009/9/25 Enrico Tröger enrico.troeger@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??
I am confused.
Cheers Lex
PS Found a workaround for entering Unicode using the Gnome character map, but its very invasive.
Am I doing something wrong or has the behaviour changed?
Not sure. I could imagine this has happened since the beginning but just nobody noticed it. At least I usually test this just with digits though I probably will change my behaviour in testing now that you mentioned it :).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 25 Sep 2009 11:12:07 +1000, Lex wrote:
2009/9/25 Enrico Tröger enrico.troeger@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?
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.
Regards, Enrico
2009/9/28 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 25 Sep 2009 11:12:07 +1000, Lex wrote:
2009/9/25 Enrico Tröger enrico.troeger@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Enrico,
Solved!!
By reading the GTK code :-( I eventually found that setting the environment variable GTK_IM_MODULE to "gtk-im-context-simple" will restore the GTK default behaviour.
A bit annoying because:
a. the value is undocumented by GTK (that I could find) b. if Geany is started by GUI menus I had to make a shell script in ~/bin (which is earlier in PATH than where Geany is) because the command specified in geany.desktop is execved not run in a shell so there is no way to set an environment variable in the desktop spec. The script sets the variable and runs the real Geany by full path.
And the answer to anyone else who gets caught is right click on an entry and see what input method is set.
Cheers Lex
2009/9/28 Lex Trotman elextr@gmail.com:
2009/9/28 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 25 Sep 2009 11:12:07 +1000, Lex wrote:
2009/9/25 Enrico Tröger enrico.troeger@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:
- it isn't a Geany problem
- it isn't a GTK problem
- 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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 29 Sep 2009 13:58:50 +1000, Lex wrote:
Hi,
Solved!!
Cool!
By reading the GTK code :-( I eventually found that setting the environment variable GTK_IM_MODULE to "gtk-im-context-simple" will restore the GTK default behaviour.
Maybe we should add this to the docs.
A bit annoying because:
a. the value is undocumented by GTK (that I could find) b. if Geany is started by GUI menus I had to make a shell script in ~/bin (which is earlier in PATH than where Geany is) because the command specified in geany.desktop is execved not run in a shell so there is no way to set an environment variable in the desktop spec. The script sets the variable and runs the real Geany by full path.
Or simply set the environment variable globally, e.g. in ~/.bashrc, ~/.profile or whereever it's appropriate for the shell you use.
Regards, Enrico