This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Tkinter doesn't handle Unicode dead key combinations on Windows
Type: Stage: resolved
Components: Tkinter, Unicode, Windows Versions: Python 3.4
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: Drekin, THRlWiTi, ezio.melotti, ned.deily, serhiy.storchaka, terry.reedy, vstinner
Priority: normal Keywords:

Created on 2014-09-14 15:44 by Drekin, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (9)
msg226872 - (view) Author: Adam Bartoš (Drekin) * Date: 2014-09-14 15:44
Key events produced on Windows handles Unicode incorrectly when Unicode character is produced by dead-key combination.

On my keyboard, (AltGr + M, a) produces several key events, last of which contains char=="a", however, it should contain "∀". Also dead-key sequence (\, a) should produce event.char=="α", however contains "?".
msg226893 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-09-15 01:36
I don't have a real Windows setup to test but I would guess this may be Tk behavior.  Perhaps the Tk wiki page on platform-specific keyboard modifier behaviors will help:
msg226906 - (view) Author: Adam Bartoš (Drekin) * Date: 2014-09-15 08:43
It seems that it's a problem of dead key combinations rather than modifiers. Unicode characters produced directly (with or without modifiers) work correctly.

Only one deadkey on my keyboard doesn't work at all. AltGr + M is a deadkey, but any following key is interpreted as if no deadkey was pressed.

On the other hand, other deadkeys including those with modifiers produces the combined characters, however usually returns just "?" as if someone applied char = char.encode("mbcs", errors="replace").decode(). E.g. whole Greek alphabet is transformed to question marks but beta is transformed to sharp s and mu to micro sign.
msg227380 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-09-23 19:43
The term 'dead key' is new to me. I found this: . 'AltGr' is also new: .  It apparently is a 'modifier' key, not a 'dead key'. Standard non-Mac US keyboards apparently have neither, so I cannot experiment or test.

Drekin, does your last comment mean that the title should be modified?
msg227385 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-09-23 20:17
Just to avoid any confusion, Apple-supplied Mac keyboards don't have an "AltGr" key.  It is found on certain PC keyboard layouts and, as such, could be used on any platform (Windows, OS X, or other Unix).
msg227388 - (view) Author: Adam Bartoš (Drekin) * Date: 2014-09-23 20:28
By modifier I mean a key like Shift, Ctrl, Alt, AltGr; or the corresponding modifier state. A combination modifier + base key produces either special action or a character or a dead key. A dead key affects the next character rather than producing a character itself. Dead keys can be even chained, i.e. a sequence [previous dead key, modifier + base key] can produce another dead key. (Aside: This feature has been present on Windows for long time, but is used very rarely and applications are buggy. I spent some time designing my Unicode keyboard layout using chained dead keys to produce various mathematical symbols. Then I found out than some applications have problems with the feature – including Firefox. It's basically because they try to implement the interpretation of keyboard layout by themselves rather then using standard Windows implementation through API.)

For example standard Czech keyboard use the AltGr key and the corresponing state to produce characters like $, #, &, @, {, }, [, ], because the top row is used for common diacritical combinations and its Shift state for numbers. I understand that English doesn't need many characters and so the layout usually doesn't need AltGr or dead keys. But I think even English keyboard should be able to type characters like English quotes, N-dash, or ellipsis: “, ”, –, ….

I have also changed the title.
msg227392 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-09-23 20:45
I guess it still comes down to whether this is an issue in tkinter or in Tk itself.  Almost all character processing and event generation is done in Tk.  One way to isolate the issue would be to use text widgets in the Tk wish shell and its demo programs.  They should be available in the ActiveState ActiveTcl distribution.  (I'm assuming that the Python Windows installer does not include wish but I don't know that for a fact.)
msg227415 - (view) Author: Adam Bartoš (Drekin) * Date: 2014-09-24 07:43
I installed wish and tried the demos shipped with Python. The behavior occurs during the demo "basic editable text". So it's an issue of Tk itself. Actually the same behavior occurs even in the wish shell.
msg227422 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-09-24 08:34
OK, then if you want to pursue the issue, I'd suggest asking on one of the Tcl/Tk forums (perhaps comp.lang.tcl) or Stackoverflow and/or checking the Tk issue tracker (  Good luck!
Date User Action Args
2022-04-11 14:58:08adminsetgithub: 66598
2015-04-27 12:52:03THRlWiTisetnosy: + THRlWiTi
2014-09-24 08:34:13ned.deilysetstatus: open -> closed
resolution: third party
messages: + msg227422

stage: resolved
2014-09-24 07:43:03Drekinsetmessages: + msg227415
2014-09-23 20:45:26ned.deilysetmessages: + msg227392
2014-09-23 20:28:13Drekinsetmessages: + msg227388
title: Tkinter doesn't handle Unicode key events on Windows -> Tkinter doesn't handle Unicode dead key combinations on Windows
2014-09-23 20:17:34ned.deilysetmessages: + msg227385
2014-09-23 19:43:41terry.reedysetnosy: + terry.reedy, serhiy.storchaka
messages: + msg227380
2014-09-15 08:43:29Drekinsetmessages: + msg226906
2014-09-15 01:36:06ned.deilysetnosy: + ned.deily
messages: + msg226893
2014-09-14 15:44:55Drekincreate