Am 21.11.14 05:49, schrieb Paul Rubin:
Terry Reedy <tjre...@udel.edu> writes:
Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives
to support astral chars: [other encodings]
This is not entirely true: Tcl supports "lazy" typing, i.e. values
(Tcl_Obj) are cast upon request into various Tcl_ObjTypes. For strings,
a dialect of UTF8 and UCS-2 are suported, where UCS-2 is called
"Uncode-string" and the UTF8-version just "string".
So in principle it would be feasible to implement something similar to
the Python flexible strig representation. The problem is that this is
only half of the story:
* There is the regexp engine. Tcl uses Henry Spencer's engine (also used
in MySQL), which is limited to UCS-2, but Spencer retired and nobody
else understands the code.
* For GUI, more support is needed e.g. to do LTR rendering. In
principle, FriBiDi can do the work http://wiki.tcl.tk/40273 , but it is
under GPL and therefore will never go into Tk
* Tk is "small" compared to other toolkits, but still large enough that
with less than half a developer currently working on it, and three
supported platforms, it is unlikely to be fixed soon
UTF-32 ... memory hit. However, most tk apps are not text heavy ...
UFT-8: Makes indexing O(n).
Given that most tk apps aren't text heavy, UTF-8 seems fine: when has
the O(n) indexing been found to be a real problem in practice?
These kind of questions are discussed in the TCT before decision which
string rep should be the default one. The text widet has other issues,
too, e.g. it is quite slow on long lines. There is a binding to
Scintilla, which could come at rescue.
Apple is a moving target, they pulled the rug from under Tk's feet
twice over the past 10 years.
Hmm interesting. Then there's also lots of new targets like mobile
phones which Tk hasn't been ported to Afaik.
Well, there is kind of a port to Android called androwish.
http://www.ch-werner.de/sdltk/AndroWish/
It is based on SDL and displays the X version on Android. In principle
it works, but never looks like a real Android app (though for games it's
great). Would be interesting to see Tkinter running there, too.
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.
The Perl people tried this earlier, IIRC - the first bindings were not
issuing Tcl commands, but calling Tk from C. It was later redesigned
like Tkinter.
Tcl itself is reasonably small and portable, the problem is the bindings
(C code) to all the different window systems Tk supports.
Tcl is not just an interpreter, but also a big C library for handling
strings, File I/O over VFS, Threads etc. All of this code in Tk would
need to be replaced. It would be an almost complete rewrite of the
non-GUI parts of Tk.
Christian
--
https://mail.python.org/mailman/listinfo/python-list
