GNOME Bugzilla – Bug 145058
Inputting "^^" requires four keystrokes on Win32, differs from platform default behaviour
Last modified: 2009-01-29 14:05:31 UTC
Alright, this mind sound a little bit silly, but please, don't laugh. Using XChat and Gaim on Windows XP, I have to perform four keystrokes in order to type "^^", which is an anime-inspired emoticon commonly used in chats nowadays. I believe this to be a bug because this behaviour is not what users expect: In normal Win32 apps, only two keystrokes are required. It's a little bit annoying, and I often hear friends complain about it after I managed to get them to try out both apps. It might be a minor problem, but it raises the barrioer of entry. (I'm not familiar with GTK+ policy on conforming to platform standards, so if this behaviour exists on purpose - I can see how it might make sense to have ^ not working on the space character -, I'm sorry for the false bug report.)
(The same applies to all dead keys, not just ^.) A related thing: In "normal" Win32 apps, typing for instance ^ followed by x gives the two characters ^x. In GTK, you get nothing (just a beep in testgtk's entry test). In a way, both the "normal" Win32 and GTK behaviours are kinda wrong IMHO. Even if there is no precomposed "LATIN SMALL LETTER X WITH CIRCUMFLEX" in Unicode, why couldn't dead keys work for any following character, and just cause that character followed by the coresponding combining diacritic character to be input? Hmm. Anyway, I don't think this isn't a big enough issue to bother fixing, unless somebody submits a patch. Setting severity to enhancement.
Fine with me. I mean, it's nothing you can't get used to -- but it's definitely annoying for new XChat/Gaim users who don't know about GTK+ at all (Win32, after all). They blame the application for having to remember this "quirk", and I haven't found a good way to explain it to them yet.
Just FYI: The behaviour that if you type ^^ you get ^^ seems to be new to Windows 2000. On an NT box, typing several ^ in a row doesn't input anything, and just the last one affects the next non-^ key you type, so that typing for instance ^^^ followed by a space you get a single ^. Maybe you should tell the XChat/Gaim users to try to write meaningful and coherent text instead of bothering with emoticons ;-)
Users don't react very well to statements like that - and why should they? How they use their apps is pretty much their business, and it's their right to shun one when it does't get the job done for them. Besides, you just used an emoticon to enhance your text as well ;). Lastly, the type of user I'm talking about never used an NT 3.x/4 box to begin with. I'm not sure how it behaves on 9x/ME; gotta test that. I'm not begging here. It's your decision, and I'm fine with it - EOD. The fact remains, however, it's one of these issues that raise the barrier of entry for many new users, even if just a little, and that's not a good thing. I certainly don't have any grasp of how thinly the devs working on GTK+ win32 are spread or what other, more important issues exist with the package, so I trust your judgement that this isn't, as you say, a big enough issue to bother fixing.
(My suggestion what to tell the users was made tongue-in-cheek, that's why I used an emoticon (smiley) myself...) (Asking mainly for Owen's and other core developer's opinion here:) The code that handles dead keys is in the backend-independent part of GTK (gtkimcontextsimple.c), isn't it? Would users of GTK on X11 be surprised if typing two dead keys started to produce two copies of the correspondind "undead" ASCII char? Or if typing a dead accent followed by a char that doesn't cause any other composed character would produce an "undead" ASCII char followed by the other char? Or should GTK even implement appending a combining diacritic if a dead key is followed by a key that doesn't form a compose sequence? Then you could input stuff like x with circumflex. A dead key followed by space probably should still compose into just the "undead" ASCII char, though. Or should a fix to the perceived problem here be in a Win32-only GtkIMContext? Or ifdeffed for Win32 only? (I hope I got the terminology correct, it's easy to mix up the keyboarding concept "compose" and the Unicode concept "combine"...)
Hmm - having fired up a KDE text editor as well as a pure Qt app on my Linux box, it appears as if Qt/X11 behaves just as GTK/X11 does. Makes me think a patch for this issue should be win32-specific, for interoperabilities sake on the Unix/Linux desktop.
In my opinion, the key handling in Win32 GTK+ by default should match as closely as possible to the handling of native windows apps. Bug 135195 is part of conforming to the native key handling, and we should be including it and be using it by default when IME is active on the system. For the non-IME case, subclassing GtkIMContextSimple seems reasonable to me if possible if we can't actually use the native win32 key translation routines; #ifdef'ing the behvaior of GtkIMContextSimple would seem strange since it is supposed to be a cross-platform input method module. I'd rather see modifications of GtkIMContextSimple to make such subclassing possible - e.g. gtk_im_context_simple_set_dead_key_behavior() than #ifdef'ing of behavior or an cut-and-paste of large portions of gtkimcontextsimple.
Is there anything happening with this bug? I just wanted to note that when typing in a foreign language keyboard layout, like Spanish, under win32 in a program like Gaim, this bug makes typing conjugations incredibly frustrating. Since the accent key is treated as a dead key, every time I want to write a word in English that is an accent followed by a consonant, I get one of two completely undesired results. I + ' + d = Incredibly loud deafening beep + frustration + "I" on screen didn + ' + t = Incredibly loud deafening beep + frustration "didn" on screen that + ' + s = No beep, but instead of "that's" i get "thatś", which is just weird. This does not behave at all like any other windows app, and would certainly frustrate anybody typing in a foreign layout. It is enough to push me away from using Gaim and look into other IM clients. At least, please, don't make it beep. That is probably the most frustrating thing of all. As above, I realize that this is a platform issue, but since GTK is supposed to be a cross-platform product, then it seems to me that from a user standpoint the fact that GTK is being used should be transparent. I would be willing to help work on a patch on this, but after I finish my study abroad in Spain.
I'm still waiting for a fix as well ;-).
> Is there anything happening with this bug? Well, as can be seen from the comments, no. Patches welcome.
*** Bug 561097 has been marked as a duplicate of this bug. ***
Brian: If you get a beep when you try to write "don't", that is then a sign that the key you think is the apostrophe key ' in fact is a (dead) acute accent key ´ or perhas even a (dead) grave accent key ` neither of which has anything to do with apostrophes as used in English. (Note that the same character is used both as apostrophe and single quote in ASCII.) Please learn to distinguish between them. It should be "don't", not "don´t". If you are using the Spanish keyboard layout, the apostrophe key is the one right of the zero key in the digit row. At least according to the Microsoft keyboard layout page http://www.microsoft.com/globaldev/reference/keyboards.mspx (works only in IE).
I wanted to get this bug a bit further to the attention of people. I recently switched to Pidgin from Trillian, and I find having to do four keystrokes instead of two most annoying. Also, in Linux this bug can be easily circumvented by using a "nodeadkeys" keyboard layout, but under Windows I have not found a way to do this. Thus, it definitely should be fixed here. There is no reason why dead key handling should stay the same that it is now. It is completely clear what the user wants when he presses the ^ key twice: he obviously wants a ^^. The bug exists for over four years now, and I would really appreciate it if we could see a fix soon. I don't even believe it would be a really hard fix, sadly my own programming skills seem not to be enough to create a patch myself (yes I tried). :/
I don't understand.. I just opened up gtk-demo on Windows Vista and starting typing ^ characters a few times in a row into a GtkEntry and a GtkTextView, and was able to do ^^ by typing it only twice, not four times.
Not so under Windows XP (SP3), I just tested it the same way. It would be weird though if GTK would behave differently under Vista. What keyboard layout do you use? Does the ^ appear immediately after pressing the key once, or do both (^^) appear only after pressing the key twice?
(In reply to comment #15) > Not so under Windows XP (SP3), I just tested it the same way. It would be weird > though if GTK would behave differently under Vista. What keyboard layout do you > use? Does the ^ appear immediately after pressing the key once, or do both (^^) > appear only after pressing the key twice? > The workaround for windows is similar to the one you described for X; you need to use a keyboard layout that doesn't use deadkeys. I use the "English (United States) - US" layout by default and it works just fine (if you use the "US International" one or another layout that uses dead keys, you'll see this behavior).
The problem is that I have a German keyboard and as such also use a German keyboard layout. And sadly there seems to be no German keyboard layout in Windows XP without dead keys. So this is sadly not a real workaround, as its use is very limited. Not to mention that in languages that actually use dead keys, it would complicate things anyways because you would not be able e.g. on a French or Spanish keyboard to type letters with certain accents.
Note that fixing this problem depends on first fixing gtkimcontextsimple so that a compose sequence can produce several characters (in this case, two). There is a bug open for that with a patch that apparently just needs some fine-tuning. Once I find out the bug number, I will mark this bug as depending on that.
I was wrong, fixing this didn't depend on fixing bug #537457. Fixed in trunk and gtk-2-14: 2009-01-29 Tor Lillqvist <tml@novell.com> Bug 145058 - Inputting "^^" requires four keystrokes on Win32, differs from platform default behaviour * gtk/gtkimcontextsimple.c (check_win32_special_case_after_compact_match): New function. Called from check_compact_table() after a table-based match has committed a character. In case there was two identical dead accents in the input, another copy of the spacing accent that was already committed is committed. This fixes #145058. (check_win32_special_cases): New function. Called first from gtk_im_context_simple_filter_keypress(). This fixes another problem: a dead accent followed by a space should commit the corresponding spacing accent. The compose tables from X commit another character in two cases and we want to override that on Windows. Add GTK_NOTE (MISC) debugging output to this code.
This should not only affect ^, but also other compose chars like for example `.
Yep, of course I fixed it in a generic fashion.