It might work with all other of *your* apps, but are you sure it works with other apps or toolkits that use significant amount of non-Microsoft code in their Windows message handling? I might imagine that for instance large specialized proprietary apps initially ported from other platforms (like CAD or EDA software) might also have similar problems. Or why not fairly specialized Open Source apps that have been ported from Unix, like Emacs for instance.

There has by the way been another bug report about AllChars, bug #330833, where the complaint was not that it wouldn't work for GTK+ apps, but that GTK+ apps would crash when AllChars is running. Apparently at least that problem (which presumably was caused by a bug in the Delphi compiler and/or runtime AllChars used) is gone then. Also, in that bug I had the impression that AllChars was dead, was that then a misconception and it in fact is in active development? Or is this a different AllChars?

By the way, the page says that "AllChars emulates the *nix Compose key on Windows". (That of course is a silly thing to say, if they mean Unix say Unix, if they mean Linux, say Linux, but Linux doesn't end with "nix". And anyway, on modern Unix and Linux desktops it is the X layer that provides Compose key functionality to apps that choose to use it, as far as I know, not the underlying OS.)

There is in fact code in GTK+ to *also* provide the same compose key features. I don't use a keyboard layout with a Compose key myself, never have, nor on X11 or on Windows. I see a discrepancy here: If you use AllChars because you want X11-like Compose key functionality, you should be able to use the same Compose key sequences already in GTK+ on Windows, too, without any AllChars. Could you be more specific in describing what key sequences it is that you are after?

Hmm, or actually, I am wrong above. There is no key in any Windows keyboard layout (thus not on any physical PC (or USB) keyboard) as far as I know that would correspond to the traditional "Multi-key" or "Compose" key as it existed on some older Unix workstation keyboards, i.e. no key that the lower levels in GTK+ would generate a GDK_Multi_key keysym from. So I guess those compose sequences that start with GDK_Multi_key can never in fact be used in GTK+ on Windows anyway.

Anyway, I am still interested in knowing which characters that aren't present on your keyboard it is that you typically want to produce. Are you sure that just switching Windows keyboard layouts wouldn't work better? Perhaps switching back and forth between several; it's easy, and the keyboard layout used is per application instance: You can have one application running with a Greek keyboard layout and another with an English one for instance. That would work fine in GTK+ (and also other apps).

(There are some known problems with GTK+ on Windows and some keyboard layouts, though: GTK+ interprets the keyboard differently than apps using Microsoft widgets. GTK+ is more eager to generate accented characters from dead keys, and especially users of the somewhat weird US International keyboard layout have complained about that, see bug #569581.)

Just FYI (and my own information;): Apparently people who nowadays use Compose/Multi_key key functionality in Linux with normal "PC" keyboard often map the Menu key (on keyboards that have it) to Multi_key. Or either Windows key.

Tor: if I find any other apps it doesn't work with, I'm going to call it a bug in those apps, too.  It works both in apps using the standard Microsoft widget libraries and in apps like Firefox that use their own.

The other bug about AllChars is most likely about an older version (v4) given the date of the bug report.  v5 is completely rewritten, uses different keyboard hooks, and is designed to be compatible with only NT and later versions of Windows (particularly Vista).  The hooks used in older AllChars have been around since the 9x days, but were deprecated and removed in Vista.  AllChars v5 uses the non-deprecated hooks.

So far as key sequences, AllChars does more than just Compose keys, so do keep that in mind.  In general though I want to be able to type accented characters, mathematical symbols, which Compose handles rather well.  I want to type them the exact same way in Pidgin that I do in Firefox, Word, Notepad, OpenOffice, or all the other apps that works with AllChars, though -- I don't want to have to memorize one way for GTK apps and another way for everything else.  Consistency trumps EVERYTHING when it comes to UIs.  (As exposition, I note that most of my Windows-using friends hated Vista for absolutely no other reason than that certain features moved from one place in the UI to another, e.g. Add/Remove Programs; as someone who's never really used Windows much before, I did not have that problem at all.  The technical issues that Linux people like to use as ammunition against Windows were total non-issues to those friends -- people just freaking hate having to relearn how to do something they already know, even if the old way wasn't as "easy to learn" as the new way.  Even the easiest thing to learn is more time consuming and frustrating than something already known -- not everyone is a geek like us, who _enjoy_ learning new things just for the thrill of it. :p )

I have absolutely no desire to switch keyboard layouts instead of using Compose.  Switching layouts when I want to type the occasional accented character is silly.  Compose provides very natural and short key sequences (é is e + ', æ is a + e, ¿ is ? + ?, etc.)  That's three keys to type a special character and be back to typing normally (which I usually want) versus a minimum of five if using keyboard layout switching with hotkeys.

And yes, I understand that AllChars does impose additional overhead for every key press.  I don't particularly care... while I'd much rather have native Compose in the toolkit(s) or OS, that just isn't the case on Windows, so I have to put up with AllChars until Microsoft removes its cranium from its colon.

Allchars 5 works with gtk+-2.24.27. It was suggested that this is a duplicate of bug 569581, but i found an older version of gtk2 where bug 569581 was still not fixed, and allchars works there as well. Maybe one of the earlier bugs fixed this. Or maybe it's because i'm testing this on Windows 10. We'll never know.

Closing this as "obsolete".

Note that allchars can't break through isolation. If you run a program as administrator, you must also run allchars as administrator.