GUI toolkit(s) status

[wxjmfauth at gmail.com]

Le vendredi 21 novembre 2014 05:35:22 UTC+1, Terry Reedy a écrit :
> 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.
> 

As you are rewriting unicode, a small suggestion/request.

Assume that one processes a part of the Bible in polytonic
Greek, one has to create a ton of temporary (locale) letters,
array of letters (you see the kind of objects).

It would be very nice if one has not to be forced to use ascii
letters to initialize those temporary strings and consequently
to save memory, it makes the code ugly (in my opinion).

>>> sys.getsizeof('a')
32
>>> sys.getsizeof('')
30

Regards.