GUI toolkit(s) status

[Christian Gollwitzer]

Am 21.11.14 05:49, schrieb Paul Rubin:
> Terry Reedy <tjreedy at 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