Best GUI for Python

[Mark Lawrence]

On 29/04/2015 05:05, Rustom Mody wrote:
> On Monday, April 27, 2015 at 12:52:48 PM UTC+5:30, Chris Angelico wrote:
>> On Mon, Apr 27, 2015 at 4:55 PM, Christian Gollwitzer  wrote:
>>> Am 27.04.15 um 01:06 schrieb Chris Angelico:
>>>>
>>>> On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney
>>>> wrote:
>>>>>
>>>>> It doesn't have to. By using the newer ‘tkinter.ttk’ library
>>>>> <URL:https://docs.python.org/3/library/tkinter.ttk.html>, the GUI will
>>>>> use native look-and-feel widgets.
>>>>>
>>>> Does the new library also deal with the ongoing issues with Unicode
>>>> support? AIUI there's some fundamental problem with Tkinter which
>>>> means that (possibly only on Windows?) non-BMP characters simply can't
>>>> be displayed.
>>>
>>>
>>> No. That is a fundamental limit in Tcl 8 (it uses UCS-2 to store strings),
>>> and will probably only addressed in Tcl 9. ttk addresses mostly the theming
>>> issue and is now "8 years new" (Tk 8.5a6) with a precursor (Tile) from ten
>>> years ago.
>>
>> Right, so this is an ongoing issue (at least for now).
>>
>>>> To me, that's a pretty bad flaw - we should be aiming
>>>> new projects at complete Unicode support, which means Python 3 and a
>>>> good GUI toolkit.
>>>
>>>
>>> YMMV. Is non-BMP needed for any living non-esoteric language? I agree that
>>> it is a big flaw, but still is useful for very many projects.
>>
>> Maybe not for the language itself, but then, you can transliterate
>> Chinese using nothing but Roman letters and Arabic numerals (all in
>> ASCII), so merely proving that you can represent text doesn't
>> necessarily mean everything. Mainly, SMP characters are used for
>> things like musical notes, mathematical symbols, emoticons, and so on.
>> (Also, I'm not sure of the current state of the art as regards Chinese
>> and Japanese characters.) If you support only the BMP, then you're far
>> better off than supporting only ASCII or only <some eight-bit code
>> page>, to be sure, but it's still cutting out some characters. For a
>> program that already exists, already works, and can't handle non-BMP
>> characters, it's a small issue, and not one that I'd be recommending a
>> complete GUI toolkit replacement for; but for a green-field project, I
>> would strongly recommend using Python 3 and some toolkit which
>> supports the full Unicode range.
>
> Everything else being equal this is likely fine advice.
> However everything is rarely equal; eg the one time I tried to use wxpython
> it segfaulted, probably the only time in 15 years of python-use that Ive
> got python to segfault.
>
>>
>> This is a problem that won't just "go away". As more SMP blocks get
>> assigned, more people will start using them, and get frustrated at
>> your program for not letting them. (And why should an end user need to
>> know the difference between 😃 and ⍥, that the second one works and
>> the first doesn't?) Unless you're willing to wait for a Python that
>> ships Tcl 9, Tkinter is a choice that restricts your end users.
>
> The issue is a bit subtle and nuanced
> Python is 2 (at least) things
> 1. A fine unicode supporting framework
> 2. A glue for putting together systems composed of various components
>
> Since some of those *other* components may break, it would be good for the
> 'glueness' of python to break more smoothly than it currently does.
>
> http://blog.languager.org/2015/03/whimsical-unicode.html#half-assed
> is a very non-exhaustive list – not just Tkinter – of
> - ostensibly unicode-supporting
> - actually SMP-borked
> software
>
> IOW it would be good if bugs (enhancements actually) like these be resolved:
>
> http://bugs.python.org/issue23672
> http://bugs.python.org/issue18814
> http://bugs.python.org/issue22264
>

Those who can do, those who can't teach :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence