After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 145058 - Inputting "^^" requires four keystrokes on Win32, differs from platform default behaviour
Inputting "^^" requires four keystrokes on Win32, differs from platform defau...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
unspecified
Other Windows
: Normal enhancement
: Small fix
Assigned To: gtk-win32 maintainers
gtk-bugs
: 561097 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-06-27 18:44 UTC by Eike Hein
Modified: 2009-01-29 14:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Eike Hein 2004-06-27 18:44:16 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.)
Comment 1 Tor Lillqvist 2004-06-30 21:15:17 UTC
(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.
Comment 2 Eike Hein 2004-06-30 21:36:05 UTC
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. 

Comment 3 Tor Lillqvist 2004-07-01 13:58:52 UTC
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 ;-)
Comment 4 Eike Hein 2004-07-01 18:59:48 UTC
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.
Comment 5 Tor Lillqvist 2004-07-02 04:39:54 UTC
(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"...)
Comment 6 Eike Hein 2004-07-02 18:04:27 UTC
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.
Comment 7 Owen Taylor 2004-07-03 08:53:02 UTC
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. 
Comment 8 Brian Saghy 2006-03-24 15:30:55 UTC
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.

Comment 9 Eike Hein 2006-03-24 16:05:20 UTC
I'm still waiting for a fix as well ;-).
Comment 10 Tor Lillqvist 2006-04-02 20:49:34 UTC
> Is there anything happening with this bug?

Well, as can be seen from the comments, no. Patches welcome.
Comment 11 Tor Lillqvist 2008-11-17 08:54:41 UTC
*** Bug 561097 has been marked as a duplicate of this bug. ***
Comment 12 Tor Lillqvist 2008-11-17 09:11:47 UTC
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).
Comment 13 Natanji 2008-12-25 13:08:34 UTC
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). :/
Comment 14 Cody Russell 2008-12-25 13:50:06 UTC
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.
Comment 15 Natanji 2008-12-25 14:38:41 UTC
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?
Comment 16 Daniel Atallah 2008-12-25 15:24:53 UTC
(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).
Comment 17 Natanji 2008-12-25 16:25:37 UTC
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.
Comment 18 Tor Lillqvist 2009-01-28 20:51:32 UTC
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.
Comment 19 Tor Lillqvist 2009-01-29 13:45:11 UTC
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.

Comment 20 Jonathan Schleifer 2009-01-29 13:53:13 UTC
This should not only affect ^, but also other compose chars like for example `.
Comment 21 Tor Lillqvist 2009-01-29 14:05:31 UTC
Yep, of course I fixed it in a generic fashion.