GUI toolkit(s) status
tjreedy at udel.edu
Fri Nov 21 05:34:37 CET 2014
On 11/20/2014 4:04 AM, Christian Gollwitzer wrote:
> Tcl nor Tk support Unicode outside the BMP. Full Unicode support is a
> big todo item on the wishlist for Tcl 9, for Tk nobody really knows. We
> are lacking manpower and people with specialized knowledge.
Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives
to support astral chars:
UTF-32 (Python's 3.2- wide build): Easy, especially starting from USC-2.
The main problem is the memory hit. However, most tk apps are not
text heavy, so this seems like a possibility. Does anyone ever try to
put a gigabyte text in a Text widget?
UTF-16 (Python's 3.2- narrow build): Easy but buggy when it comes to
indexing and slicing.
UTF-16+: I posted on the tracker a prototype of how to make indexing
correct by adding an auxiliary index of non-BMP chars. It makes
indexing O(k), where k is the number of astral chars.
UFT-8: Makes indexing O(n).
Python FSR (3.3+ Unicode): Handling variable byte width adds complexity,
but Python has already implemented this pretty efficiently. Python is
open source with a liberal licenc
To me, an important consideration for choosing is what the OSes require
to put characters on the screen. Are they all the same?
> Apple is a
> moving target, they pulled the rug from under Tk's feet twice over the
> past 10 years. Nobody knows if Tk will continue to exist on the mac if
> Cocoa is withdrawn some day and replaced by a new and completely
> different windowing framework.
> Python has largely replaced Tcl as the
> first-choice scripting language, and that also does not help to attract
> people working on Tcl/Tk.
A possible solution for Tk is to replace the non-C Tcl parts of TK with
Python (or the CPython API functions as needed for speed). I have no
idea how horrendous a project creating Py/Tk would be.
Terry Jan Reedy
More information about the Python-list