GNOME Bugzilla – Bug 148386
GTK+ on Windows doesn't support ALT+keypad digits to input arbitrary characters
Last modified: 2018-04-15 00:29:51 UTC
On Windows, most applications support pressing ALT+keycode to insert the key code's ASCII or Unicode character. E.g. ALT+174 gives « and ALT+175 gives ». This does absolutely nothing in Gaim, which is built on GTK+. The Gaim developers seem to think that this is a problem with GTK+ and not with Gaim itself: https://sourceforge.net/tracker/index.php? func=detail&aid=997306&group_id=235&atid=100235 I don't know what to make of it, and who's to blame:
Yes this is a GTK+ limitation. I have tested on Windows XP using gtk-2-4 from CVS using the gtk-demo program, and Alt+numbers doesn't work. This is because GTK+ on Win32 no longer uses the WM_CHAR message but instead handles WM_(SYS)KEYDOWN and WM_(SYS)KEYUP itself. Quote from ChangeLog.pre-2-4 (2003-07-25, tml): Another side-effect is that Alt+keypad digits don't work any longer, but it's better to learn to use GTK's ISO14755 support is anyway. So you should be able to press and hold Ctrl+Shift and then type in the Unicode character number (or whatever it is called) in hexadecimal, for example Ctrl+Shift+bb gives me the "»" character in a GTK+ text input field. At least in Windows XP you can use the Character Map application (accessories-system tools) to see which Unicode number to use.
I don't understand how it's better for Windows users to learn GTK's internal way to handle such things, but as I have no time to waste on a minor bug like this, CTRL+SHIFT+ab for « and CTRL+SHIFT+bb for » works just fine for me. Thanks!
Unicode code point ("character") values in hexadecimal is in no way a concept restricted to GTK. Hexadecimal is the canonical way to refer to Unicode code points, usually written like U+00BB (for ») in running text. Modern (NT-based) Windows has used Unicode since the beginning, so Unicode should hopefully be a relatively familiar concept to Windows users. My opinion is that code pages (which is what the Alt+keypad numbers convention refers to) are a thing best forgotten anyway. Still, it definitely would be a good idea to support Alt+keypad numbers, as many users are used to that, without really understanding the underlying issues, and that code pages actually are a Bad Idea... Patches accepted... This might actually be a duplicate of an existing bug or enhancement request, but I couldn't find it right now.
*** Bug 154509 has been marked as a duplicate of this bug. ***
Windows also supports ALT+####, where the #s are the Unicode value in decimal. For example, ALT+130 does the same as ALT+0233, and you'll note that e9 in base 16 = 233 in decimal. So, perhaps adding the additional interface to GTK's existing Unicode entry is possible?
The documentation at <http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp? url=/windowsxp/home/using/productdoc/en/lang_char_code_input.asp> (cut&paste that into a single URL) doesn't say so. It seems to say that Alt+0### refers to a code in the current "ANSI" code page (like 1252 for Latin-1-ish, or 1252 for Cyrillic), not Unicode. And anyway, Unicode code points are almost universally specified as hex (the well-known U+00E9 notation). Even if Alt+0#### would mean Unicode code points in decimal, that would be a very uncommon way to refer to them. The Unicode standard, the Unicode mailing list, etc all use the U+hex digits notation. Decimal values for Unicode code points aren't even listed in the Unicode standard.
(Brianstorming out loud...) So, for this bug to be solved, its solution must implement either the ALT+1## or ALT+0### in such a way that GTK knows how to handle the mapping from code pages to Unicode? Does there exist anything in GTK currently that defines either an input language (ALT+0###) or a system language (ALT+1##), the concepts to which the document at that URL refers?
The Alt+### would make sense only on Windows anyway, so the code would use the normal Win32 API. GetACP() and GetOEMCP() returns the relevant code page numbers, then sprintf that into "CP%d" to get the charset name to pass to g_convert(). Or, simpler, just call MultiByteToWideChar() specifying CP_ACP or CP_OEMCP. The document is a bit vague when it talks about "languages", I assume what they actually mean is the so-called "ANSI" (which in this context has nothing to do with American National Standards Institute any longer) and "OEM" code pages used by said languages.
Another problem with the Ctrl+Shift method is that some programs override Ctrl+Shift+[ABCDEF] at the system level, making it impossible to enter certain character codes. Stardock's CursorXP, for instance, traps Ctrl+Shift+C by default, though at least in the case of CursorXP the hotkey can be changed. In WordPad, Word and Internet Explorer, it appears that any character code up to 0255 entered with Alt is handled by the system code page, and 0256 and above are treated as Unicode-- a rather interesting kludge that's *not* standard within all Windows apps.
The problem that Ctrl+Shift+hex can clash with accelerators is the subject of a longstanding bug here, bug #82011.
*** Bug 312255 has been marked as a duplicate of this bug. ***
*** Bug 537643 has been marked as a duplicate of this bug. ***
The current status of the bug is that personally I currently lack the inspiration to implement the functionality asked for, but if somebody submits a clean patch, sure, it could be applied.
GTK+ now uses the sequece Ctrl+Shift+u to initiate a sequence to type Unicode characters by their hex value. Specifically, /* In addition to the table-driven sequences, we allow Unicode hex * codes to be entered. The method chosen here is similar to the * one recommended in ISO 14755, but not exactly the same, since we * don't want to steal 16 valuable key combinations. * * A hex Unicode sequence must be started with Ctrl-Shift-U, followed * by a sequence of hex digits entered with Ctrl-Shift still held. * Releasing one of the modifiers or pressing space while the modifiers * are still held commits the character. It is possible to erase * digits using backspace. * * As an extension to the above, we also allow to start the sequence * with Ctrl-Shift-U, then release the modifiers before typing any * digits, and enter the digits without modifiers. */ See http://svn.gnome.org/svn/gtk+/trunk/gtk/gtkimcontextsimple.c It is match more powerful to use the way that GTK+ implements the writing of Unicode characters by their hex value. I would consider having programs such as Pidgin detect when a user tries to type a character in the old way, then propose the way that GTK+ does it.
Note that the RichEdit control on Windows also supports entering Unicode characters through their hex codepoints: type the hex character code and press Alt+X (note: you need to select the code first if there's [0-9a-f] in front of it, as it'll try to consume up to 5 hex digits in front of cursor otherwise). I personally find this way of entering hex codes easier than GTK+'s.
*** Bug 596914 has been marked as a duplicate of this bug. ***
Comment #13 is still true. Editing the summary a bit to drop the somewhat vague "keycode" term. It is not (hardware) keycodes that are relevant here.
The default input method's Crtl+Shift+U, type code point, {Space | release Ctrl+Shift if you were holding them} to commit that Simos mentions in #14 works quite well. Been using it for some time. Nice UI, actually. I'm sure we'll never get past "but in Windows it works $that way", but for people using GNOME this works great. AfC
Yeah, if some Alt+keypad-digits method was implemented and accepted, it for sure would be used only on Windows.
It's a damned PLATFORM STANDARD. GTK should support Alt+#, Alt+0# and Alt++XXX combination as any other Windows application.
Maybe you need to ask for your money back then.
I have noted this behavior by using Geany, a (very nice) GTK+ text editor. I discovered it on Ubuntu, loved it, and installed it on my Windows XP machine as well, only to discover that the usual way of entering special characters (i.e. the so called "alt codes") doesn't work. After some research, I found the ctrl+shift+u method, and read all over the place that it is more powerful than the alt codes. Although it seems like a more consistent way of writing special characters, it suffers from a few problems (noted in Geany, Windows version) : - you actually have to keep the ctrl+shift buttons pressed while entering the code, which can lead to inconvenient finger configurations. - as a result, since shift is pressed, numbers from the numpad do not work, and one has to use the numbers that are located "above the letters". French people rarely use those, because they have to be reached by pressing shift, which is less convenient. - for some reason, the '0' (zero) character could only be entered if ctrl+shift+alt was pressed. - and last but not least, it is not the standard behavior for a Windows application. I think that people are used to the fact the input method depends on the operating system, but certainly not on the application. Adding the ctrl+shift+u method is a good thing, if some people prefer to have a platform independent way to input special characters, but I really think that you should still support the alt codes for Windows (and Windows only, since it doesn't make sense in other platforms anyway). You are probably right in saying that the ctrl+shift+u method is better, but you should really keep in mind that this goes against the habits of people who have used the alt codes for years, and expect them to be functional in every Windows application. So what about Comment #13 today, in 2012 ?
Kalith: As for my personal involvement, see http://tml-blog.blogspot.fi/2011/03/gtk-on-windows-i-am-not-really-doing-it.html . The "patches welcome" aspect still holds, as far as I know.
I understand your situation, for I have been there myself as well (though on a much smaller scale project). Still, as can be read in your blog post, there are other people working on GTK+ for Windows. Has this issue come to their attention ? As for the patch, I have no experience in GTK programming, nor in handling input from Windows primitives. I guess that, since nobody wrote this patch during the last 8 years, nobody will. After all, maybe there are not so many people that actually consider this as an issue ?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new