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 148386 - GTK+ on Windows doesn't support ALT+keypad digits to input arbitrary characters
GTK+ on Windows doesn't support ALT+keypad digits to input arbitrary characters
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
unspecified
Other Windows
: Normal enhancement
: Medium feature
Assigned To: gtk-win32 maintainers
gtk-bugs
: 154509 312255 537643 596914 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-07-25 01:02 UTC by Asbjørn Ulsberg
Modified: 2018-04-15 00:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Asbjørn Ulsberg 2004-07-25 01:02:58 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:
Comment 1 Robert Ögren 2004-07-27 20:18:53 UTC
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.
Comment 2 Asbjørn Ulsberg 2004-07-27 21:15:11 UTC
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!
Comment 3 Tor Lillqvist 2004-07-31 17:51:49 UTC
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.
Comment 4 Tor Lillqvist 2004-10-05 07:20:45 UTC
*** Bug 154509 has been marked as a duplicate of this bug. ***
Comment 5 Felipe Gasper 2004-10-05 14:32:19 UTC
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?
Comment 6 Tor Lillqvist 2004-10-05 16:17:13 UTC
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.
Comment 7 Felipe Gasper 2004-10-05 17:01:34 UTC
(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?
Comment 8 Tor Lillqvist 2004-10-05 17:23:28 UTC
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.
Comment 9 Cody B. 2005-01-09 05:34:34 UTC
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.
Comment 10 Tor Lillqvist 2005-01-09 17:56:47 UTC
The problem that Ctrl+Shift+hex can clash with accelerators is the subject of a
longstanding bug here, bug #82011.
Comment 11 Olav Vitters 2005-08-01 16:53:12 UTC
*** Bug 312255 has been marked as a duplicate of this bug. ***
Comment 12 Olav Vitters 2008-06-10 18:24:25 UTC
*** Bug 537643 has been marked as a duplicate of this bug. ***
Comment 13 Tor Lillqvist 2008-06-10 21:06:25 UTC
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.
Comment 14 Simos Xenitellis 2008-07-14 13:12:14 UTC
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. 
Comment 15 Jernej Simončič 2009-04-27 15:30:30 UTC
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.
Comment 16 Tor Lillqvist 2009-10-01 02:37:27 UTC
*** Bug 596914 has been marked as a duplicate of this bug. ***
Comment 17 Tor Lillqvist 2009-10-01 02:42:19 UTC
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.
Comment 18 Andrew Cowie 2009-10-01 03:16:12 UTC
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
Comment 19 Tor Lillqvist 2009-10-01 09:24:00 UTC
Yeah, if some Alt+keypad-digits method was implemented and accepted, it for sure would be used only on Windows.
Comment 20 Urmas 2012-04-14 08:11:11 UTC
It's a damned PLATFORM STANDARD. GTK should support Alt+#, Alt+0# and Alt++XXX combination as any other Windows application.
Comment 21 Tor Lillqvist 2012-04-24 14:25:22 UTC
Maybe you need to ask for your money back then.
Comment 22 Kalith 2012-06-07 10:26:46 UTC
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 ?
Comment 23 Tor Lillqvist 2012-06-08 08:46:43 UTC
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.
Comment 24 Kalith 2012-06-08 09:18:17 UTC
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 ?
Comment 25 Matthias Clasen 2018-02-10 05:23:11 UTC
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.
Comment 26 Matthias Clasen 2018-04-15 00:29:51 UTC
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