GUI toolkit(s) status

[Terry Reedy]

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