Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #89415 > unrolled thread

Best GUI for Python

Back to article view | Back to comp.lang.python

Contents

  Best GUI for Python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-26 15:02 +0200
    Re: Best GUI for Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-27 01:09 +1000
      Re: Best GUI for Python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-26 18:32 +0200
        Re: Best GUI for Python Gary Herron <gherron@digipen.edu> - 2015-04-26 10:12 -0700
          Re: Best GUI for Python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-26 20:07 +0200
            Re: Best GUI for Python IronManMark20 <mr.smittye@gmail.com> - 2015-04-26 12:04 -0700
            Re: Best GUI for Python Gary Herron <gary.herron@islandtraining.com> - 2015-04-26 13:06 -0700
      Re: Best GUI for Python Ben Finney <ben+python@benfinney.id.au> - 2015-04-27 06:26 +1000
        Re: Best GUI for Python Grant Edwards <invalid@invalid.invalid> - 2015-04-27 17:02 +0000
          Re: Best GUI for Python Christian Gollwitzer <auriocus@gmx.de> - 2015-04-27 23:17 +0200
            Re: Best GUI for Python Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-04-28 08:05 +0100
      Re: Best GUI for Python Chris Angelico <rosuav@gmail.com> - 2015-04-27 09:06 +1000
        Re: Best GUI for Python Christian Gollwitzer <auriocus@gmx.de> - 2015-04-27 08:55 +0200
          Re: Best GUI for Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-27 17:15 +1000
            Re: Best GUI for Python Christian Gollwitzer <auriocus@gmx.de> - 2015-04-27 16:54 +0200
              Re: Best GUI for Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-28 02:31 +1000
          Re: Best GUI for Python Chris Angelico <rosuav@gmail.com> - 2015-04-27 17:22 +1000
            Re: Best GUI for Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-28 15:10 +1000
              Re: Best GUI for Python Chris Angelico <rosuav@gmail.com> - 2015-04-28 15:32 +1000
                Re: Best GUI for Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-28 16:43 +1000
                  Re: Best GUI for Python Chris Angelico <rosuav@gmail.com> - 2015-04-28 16:59 +1000
                    Re: Best GUI for Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-28 17:54 +1000
                      Re: Best GUI for Python Christian Gollwitzer <auriocus@gmx.de> - 2015-04-28 10:00 +0200
                      Re: Best GUI for Python Chris Angelico <rosuav@gmail.com> - 2015-04-28 18:07 +1000
            Re: Best GUI for Python Rustom Mody <rustompmody@gmail.com> - 2015-04-28 21:05 -0700
              Re: Best GUI for Python wxjmfauth@gmail.com - 2015-04-29 00:00 -0700
              Re: Best GUI for Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-29 10:03 +0100
    Re: Best GUI for Python Cecil Westerhof <Cecil@decebal.nl> - 2015-04-26 18:16 +0200
      Re: Best GUI for Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-26 18:08 +0100
    Re: Best GUI for Python wxjmfauth@gmail.com - 2015-04-27 02:02 -0700
    Re: Best GUI for Python Dave Cook <davecook@nowhere.net> - 2015-04-28 17:22 +0000

Page 1 of 2  [1] 2  Next page →

#89415 — Best GUI for Python

I want to use a GUI for Python. When searching I found (beside some
others) Tkinter and wxPython. From what I found it looks like Tkinter
is slightly better. What would be the pros/cons of these two? Would
there be a compelling reason to use another GUI?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#89420

On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote:

> I want to use a GUI for Python. When searching I found (beside some
> others) Tkinter and wxPython. From what I found it looks like Tkinter
> is slightly better. What would be the pros/cons of these two? Would
> there be a compelling reason to use another GUI?

Tkinter is easier to use, as it is standard with Python. So long as you have
Tk/Tcl installed on your computer, Tkinter should work fine.

However, Tkinter probably looks a bit more old fashioned.

wxPython probably looks a bit more modern and may be a bit more powerful,
but it will require a large extra library. It's also a lot harder to learn
to use wxPython unless you are comfortable with C++ programming.


Have you seen this?

https://wiki.python.org/moin/GuiProgramming
‎


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#89423

Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano:

> On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote:
>
>> I want to use a GUI for Python. When searching I found (beside some
>> others) Tkinter and wxPython. From what I found it looks like
>> Tkinter is slightly better. What would be the pros/cons of these
>> two? Would there be a compelling reason to use another GUI?
>
> Tkinter is easier to use, as it is standard with Python. So long as
> you have Tk/Tcl installed on your computer, Tkinter should work
> fine.
>
> However, Tkinter probably looks a bit more old fashioned.
>
> wxPython probably looks a bit more modern and may be a bit more
> powerful, but it will require a large extra library. It's also a lot
> harder to learn to use wxPython unless you are comfortable with C++
> programming.

Well, I did my share of C++ programming. ;-)


> Have you seen this?
>
> https://wiki.python.org/moin/GuiProgramming

Dabo looks interesting, but also a little bit dead. Well, maybe I just
should evaluate Tkinter and wxPython both. Now wxPython looks more
interesting. But it is easier to make a reasonable decision when I
have a little more information. :-D

For the moment I limit it to Tkinter and wxPython.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#89425

On 04/26/2015 09:32 AM, Cecil Westerhof wrote:
> Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano:
>
>> On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote:
>>
>>> I want to use a GUI for Python. When searching I found (beside some
>>> others) Tkinter and wxPython. From what I found it looks like
>>> Tkinter is slightly better. What would be the pros/cons of these
>>> two? Would there be a compelling reason to use another GUI?
>> Tkinter is easier to use, as it is standard with Python. So long as
>> you have Tk/Tcl installed on your computer, Tkinter should work
>> fine.
>>
>> However, Tkinter probably looks a bit more old fashioned.
>>
>> wxPython probably looks a bit more modern and may be a bit more
>> powerful, but it will require a large extra library. It's also a lot
>> harder to learn to use wxPython unless you are comfortable with C++
>> programming.
> Well, I did my share of C++ programming. ;-)
>
>
>> Have you seen this?
>>
>> https://wiki.python.org/moin/GuiProgramming
> Dabo looks interesting, but also a little bit dead. Well, maybe I just
> should evaluate Tkinter and wxPython both. Now wxPython looks more
> interesting. But it is easier to make a reasonable decision when I
> have a little more information. :-D
>
> For the moment I limit it to Tkinter and wxPython.

I wouldn't recommend limiting yourself like that.  I've used both 
successively (years ago),  then pyGTK for a batch of projects, followed 
by pyglet for some years and many projects, and most recently PyQt.    
They are all worthy GUI programming libraries, and each of them is cross 
platform (as I required to develop on Linux, but deploy occasionally on 
Windows).




-- 
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418

[toc] | [prev] | [next] | [standalone]

#89426

Op Sunday 26 Apr 2015 19:12 CEST schreef Gary Herron:

> On 04/26/2015 09:32 AM, Cecil Westerhof wrote:
>> Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano:
>>
>>> On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote:
>>>
>>>> I want to use a GUI for Python. When searching I found (beside
>>>> some others) Tkinter and wxPython. From what I found it looks
>>>> like Tkinter is slightly better. What would be the pros/cons of
>>>> these two? Would there be a compelling reason to use another GUI?
>>> Tkinter is easier to use, as it is standard with Python. So long
>>> as you have Tk/Tcl installed on your computer, Tkinter should work
>>> fine.
>>>
>>> However, Tkinter probably looks a bit more old fashioned.
>>>
>>> wxPython probably looks a bit more modern and may be a bit more
>>> powerful, but it will require a large extra library. It's also a
>>> lot harder to learn to use wxPython unless you are comfortable
>>> with C++ programming.
>> Well, I did my share of C++ programming. ;-)
>>
>>
>>> Have you seen this?
>>>
>>> https://wiki.python.org/moin/GuiProgramming
>> Dabo looks interesting, but also a little bit dead. Well, maybe I
>> just should evaluate Tkinter and wxPython both. Now wxPython looks
>> more interesting. But it is easier to make a reasonable decision
>> when I have a little more information. :-D
>>
>> For the moment I limit it to Tkinter and wxPython.
>
> I wouldn't recommend limiting yourself like that. I've used both
> successively (years ago), then pyGTK for a batch of projects,
> followed by pyglet for some years and many projects, and most
> recently PyQt. They are all worthy GUI programming libraries, and
> each of them is cross platform (as I required to develop on Linux,
> but deploy occasionally on Windows).

I did say for the moment. ;-)

But just curious: what is the reason you use five different kinds of
GUI? It seems like it makes think difficult for you. I mean the
question as enlightenment for myself.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#89428

> 
> But just curious: what is the reason you use five different kinds of
> GUI? It seems like it makes think difficult for you. I mean the
> question as enlightenment for myself.

A good question :). Most of this comes from the openness to create binding for many projects. Tkinter is a binding of Tk. pyGTK is a binding of GTK, which is written in c++, the same is true of PyQt/PySide, which binds Qt. wxPython binds wxWidgets. 

I find the variation good, because it means there are more choices. I use PyQt, because I wanted very cross platform code, other choose pyGTK because they want to closely integrate with the GTK environment. 

Your choice of GUI library depends on what you are targeting.

[toc] | [prev] | [next] | [standalone]

#89430

On 04/26/2015 11:07 AM, Cecil Westerhof wrote:
> Op Sunday 26 Apr 2015 19:12 CEST schreef Gary Herron:
>
>> On 04/26/2015 09:32 AM, Cecil Westerhof wrote:
>>> Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano:
>>>
>>>> On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote:
>>>>
>>>>> I want to use a GUI for Python. When searching I found (beside
>>>>> some others) Tkinter and wxPython. From what I found it looks
>>>>> like Tkinter is slightly better. What would be the pros/cons of
>>>>> these two? Would there be a compelling reason to use another GUI?
>>>> Tkinter is easier to use, as it is standard with Python. So long
>>>> as you have Tk/Tcl installed on your computer, Tkinter should work
>>>> fine.
>>>>
>>>> However, Tkinter probably looks a bit more old fashioned.
>>>>
>>>> wxPython probably looks a bit more modern and may be a bit more
>>>> powerful, but it will require a large extra library. It's also a
>>>> lot harder to learn to use wxPython unless you are comfortable
>>>> with C++ programming.
>>> Well, I did my share of C++ programming. ;-)
>>>
>>>
>>>> Have you seen this?
>>>>
>>>> https://wiki.python.org/moin/GuiProgramming
>>> Dabo looks interesting, but also a little bit dead. Well, maybe I
>>> just should evaluate Tkinter and wxPython both. Now wxPython looks
>>> more interesting. But it is easier to make a reasonable decision
>>> when I have a little more information. :-D
>>>
>>> For the moment I limit it to Tkinter and wxPython.
>> I wouldn't recommend limiting yourself like that. I've used both
>> successively (years ago), then pyGTK for a batch of projects,
>> followed by pyglet for some years and many projects, and most
>> recently PyQt. They are all worthy GUI programming libraries, and
>> each of them is cross platform (as I required to develop on Linux,
>> but deploy occasionally on Windows).
> I did say for the moment. ;-)
>
> But just curious: what is the reason you use five different kinds of
> GUI? It seems like it makes think difficult for you. I mean the
> question as enlightenment for myself.
>

Yikes,  Stated like that it does sound excessive but in reality it's 
spread over about 20 years of Python and graphics/GUI programming. 
Experimenting with a new GUI every 5 years or so  just keeps the 
interest levels up.

[toc] | [prev] | [next] | [standalone]

#89431

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Tkinter is easier to use, as it is standard with Python. So long as
> you have Tk/Tcl installed on your computer, Tkinter should work fine.
>
> However, Tkinter probably looks a bit more old fashioned.

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.

Why not by default? To preserve backward compatibility. There are some
old GUI programs using basic Tkinter, and breaking the GUI is not a good
thing to do to programs which are otherwise working fine. So you only
get the newer widgets by asking for them explicitly.

-- 
 \        “Members of the general public commonly find copyright rules |
  `\        implausible, and simply disbelieve them.” —Jessica Litman, |
_o__)                                              _Digital Copyright_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#89467

On 2015-04-26, Ben Finney <ben+python@benfinney.id.au> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>
>> Tkinter is easier to use, as it is standard with Python. So long as
>> you have Tk/Tcl installed on your computer, Tkinter should work fine.
>>
>> However, Tkinter probably looks a bit more old fashioned.
>
> 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.

I've tried using ttk, and it's not too bad on Windows, but it doesn't
seem to help a jot on Linux. Most Linux users seem to be able to cope
without a problem, but the old gray Motify look seems a bit dated.
When I do try to use ttk on Linux, I just seem to end up with a
mixture of two different completely non-native vaguely retro-looking
widgets.

-- 
Grant Edwards               grant.b.edwards        Yow! All this time I've
                                  at               been VIEWING a RUSSIAN
                              gmail.com            MIDGET SODOMIZE a HOUSECAT!

[toc] | [prev] | [next] | [standalone]

#89470

Am 27.04.15 um 19:02 schrieb Grant Edwards:
> On 2015-04-26, Ben Finney <ben+python@benfinney.id.au> wrote:
>> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>>
>>> Tkinter is easier to use, as it is standard with Python. So long as
>>> you have Tk/Tcl installed on your computer, Tkinter should work fine.
>>>
>>> However, Tkinter probably looks a bit more old fashioned.
>>
>> 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.
>
> I've tried using ttk, and it's not too bad on Windows, but it doesn't
> seem to help a jot on Linux. Most Linux users seem to be able to cope
> without a problem, but the old gray Motify look seems a bit dated.
> When I do try to use ttk on Linux, I just seem to end up with a
> mixture of two different completely non-native vaguely retro-looking
> widgets.

Yes, the default theme is terrible on Linux (Mac & Windows uses native 
widgets). There are additional themes available, which are buried in 
some packages and a bit difficult to install, but give reasonable 
approximations to the QT look; I'm talking about plastik, for instance 
http://wiki.tcl.tk/24094 (1st picture - the layout of the test is 
terrible, but the widgets do look good). For some reason I've got no 
insights, these themes are very slow (they are based on displaying 
pre-rendered PNG images for the widget bits and pieces).
Yet another possibility are the tileQT and tileGTK packages, which 
render the widgets using QT and GTK, but of course this introduces these 
dependencies and it might be simpler to just use QT or GTK natively.

	Christian

>

[toc] | [prev] | [next] | [standalone]

#89485

Christian Gollwitzer <auriocus@gmx.de> wrote:

>Yes, the default theme is terrible on Linux (Mac & Windows uses native 
>widgets). There are additional themes available, which are buried in 
>some packages and a bit difficult to install, but give reasonable 
>approximations to the QT look; I'm talking about plastik, for instance 
>http://wiki.tcl.tk/24094 (1st picture - the layout of the test is 
>terrible, but the widgets do look good). For some reason I've got no 
>insights, these themes are very slow (they are based on displaying 
>pre-rendered PNG images for the widget bits and pieces).
>Yet another possibility are the tileQT and tileGTK packages, which 
>render the widgets using QT and GTK, but of course this introduces these 
>dependencies and it might be simpler to just use QT or GTK natively.

Yes, in the case of a more complex control-panel interface, it becomes
worthwhile to design it with a GUI designer like Glade anyway, so that
would give it the "gi" GTk3 widget set which looks fine.

Tkinter is OK if you want to make something utilitarian like an
oscilloscope interface and it does seem to be the easiest way to build
an interface without a GUI builder.

Kivy isn't bad, being fairly easy to use without a GUI designer, and
having a modern flat smartphone-style widget set, if you like that sort
of thing. You're expected to give the buttons logos and different
colours.

[toc] | [prev] | [next] | [standalone]

#89433

On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>
>> Tkinter is easier to use, as it is standard with Python. So long as
>> you have Tk/Tcl installed on your computer, Tkinter should work fine.
>>
>> However, Tkinter probably looks a bit more old fashioned.
>
> 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.
>
> Why not by default? To preserve backward compatibility. There are some
> old GUI programs using basic Tkinter, and breaking the GUI is not a good
> thing to do to programs which are otherwise working fine. So you only
> get the newer widgets by asking for them explicitly.

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. 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.

PyGTK is a bit clunky in some areas, but I have GTK experience from
other languages, so that's the one I personally use.

ChrisA

[toc] | [prev] | [next] | [standalone]

#89447

Am 27.04.15 um 01:06 schrieb Chris Angelico:
> On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney <ben+python@benfinney.id.au> 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.


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.

	Christian

[toc] | [prev] | [next] | [standalone]

#89448

On Monday 27 April 2015 16:55, Christian Gollwitzer wrote:

> 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.

Yes.

The Unicode Supplementary Multilingual Planes (SMPs) are used for rare but 
still current East Asian characters (which means that some of your Chinese 
users may not be able to write their names without it), also some 
mathematics symbols (okay, that's *slightly* esoteric), as well as emoji.

None of those uses are critical (unless you have a lot of Chinese users) but 
supporting the SMPs should not be considered optional.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#89461

Am 27.04.15 um 09:15 schrieb Steven D'Aprano:
> On Monday 27 April 2015 16:55, Christian Gollwitzer wrote:
>
>> 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.
>
> Yes.
>
> The Unicode Supplementary Multilingual Planes (SMPs) are used for rare but
> still current East Asian characters (which means that some of your Chinese
> users may not be able to write their names without it), also some
> mathematics symbols (okay, that's *slightly* esoteric), as well as emoji.

OK current Chinese characters count in. Were these available in 
pre-unicode 16bit encodings? If not, how did they cope? Not rying to 
defend the BMP, but still wondering whether this is a new issue due to 
the switch from 16bit to unicode, or if people can finally use all 
characters thanks to unicode (software with full support). Emoji and 
rare math is somewhat more esoteric (given the limited codepoint space)

> None of those uses are critical (unless you have a lot of Chinese users) but
> supporting the SMPs should not be considered optional.

I fully agree. Full unicode is one of the goals for Tcl9, but Tcl/Tk is 
missing manpower to actually implement that stuff (and people with 
skills in unicode platform APIs)

	Christian

[toc] | [prev] | [next] | [standalone]

#89466

On Tue, 28 Apr 2015 12:54 am, Christian Gollwitzer wrote:

> Am 27.04.15 um 09:15 schrieb Steven D'Aprano:
>> On Monday 27 April 2015 16:55, Christian Gollwitzer wrote:
>>
>>> 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.
>>
>> Yes.
>>
>> The Unicode Supplementary Multilingual Planes (SMPs) are used for rare
>> but still current East Asian characters (which means that some of your
>> Chinese users may not be able to write their names without it), also some
>> mathematics symbols (okay, that's *slightly* esoteric), as well as emoji.
> 
> OK current Chinese characters count in. Were these available in
> pre-unicode 16bit encodings? 

Certainly not :-)

Unicode currently encodes over 74,000 CJK (Chinese/Japanese/Korean)
ideographs, which is comfortably larger than 2**16, so no 16-bit encoding
can handle the complete range of CJK characters. In fact, Unicode has
projected that at least another five thousand characters will be added in
version 8, and probably more beyond that.


> If not, how did they cope? 

Mostly badly :-)

Actually, that's probably unfair. The situation wasn't as bad as it could
have been for a number of reasons:

- In Korea, hanja (literally "Chinese characters") are mostly used for older
historical documents and some names, so most new documents would be written
entirely in hangul instead of Chinese ideographs.

- In Japan, kanji (also literally "Chinese characters") are not the only
option either. There is a choice between kanji and three other systems:

  hiragana is used for syllables and words for which there is either 
  no kanji available, or the author doesn't know the kanji;

  katakana is used for foreign words, loan words, scientific and 
  technical terms, the names of companies, for emphasis, and 
  onomatopoeia (words that sound like the sound of the thing they
  describe, e.g. bling, splash, pow, fizz, cock-a-doodle-do, oink);

  rōmaji (literally "Roman letters"), although it is rare to use
  that to write Japanese; it's mostly used for communication with
  non-Japanese, and as an input system for entering kanji.

- 16 bits is enough to do the most common Chinese characters. For less
common characters, people can re-word the phrase, use alternative spelling,
or use a custom font or image, depending on how important the exact correct
character is considered.

- When it comes to names, sometimes people can use a similar character. The
nearest approximation in Latin languages would be if the preferred spelling
of your name was Zöe Weiß and you wrote Zoe Weiss instead.

- Vietnam hasn't used Chinese characters (Nôm) since the 1920s, except for
limited use as decorative and ceremonial uses.


Disclaimer: nearly all of the above is taken from Wikipedia, my personal
knowledge of Chinese and Japanese is limited to "yum cha" and "banzai".
Everything else is all Greek to me :-) Consequently actual speakers of CJK
languages may have different opinions.


> Not rying to  
> defend the BMP, but still wondering whether this is a new issue due to
> the switch from 16bit to unicode, or if people can finally use all
> characters thanks to unicode (software with full support). Emoji and
> rare math is somewhat more esoteric (given the limited codepoint space)

No, it is not a new issue. Legacy East-Asian encodings have the same
problems. It will probably take many more years before the entire CJK
character set is added to Unicode, simply because the characters left to
add are obscure and rare. Some may never be added. E.g. in 2007 Taiwan
withdrew a submission to add 6,545 characters used as personal names as
they were deemed to no longer be in use.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#89449

On Mon, Apr 27, 2015 at 4:55 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> Am 27.04.15 um 01:06 schrieb Chris Angelico:
>>
>> On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney <ben+python@benfinney.id.au>
>> 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.

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.

ChrisA

[toc] | [prev] | [next] | [standalone]

#89477

On Monday 27 April 2015 17:22, Chris Angelico wrote:

> 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.

I'm not really arguing with you, just giving a slightly difference of 
emphasis...

I don't think that failure to support the SMPs is a deal-breaker. Obviously, 
if you specifically need some subset of Unicode in the SMPs, say Phoenician, 
then it may be, but I'm just talking about general use. Given the generally 
poor support for non-ASCII characters many applications provide, any Unicode 
support is better than none.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#89479

On Tue, Apr 28, 2015 at 3:10 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Monday 27 April 2015 17:22, Chris Angelico wrote:
>
>> 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.
>
> I'm not really arguing with you, just giving a slightly difference of
> emphasis...
>
> I don't think that failure to support the SMPs is a deal-breaker. Obviously,
> if you specifically need some subset of Unicode in the SMPs, say Phoenician,
> then it may be, but I'm just talking about general use. Given the generally
> poor support for non-ASCII characters many applications provide, any Unicode
> support is better than none.

I agree that it isn't _in itself_ a deal-breaker; it's a choice, but
most choices restrict you, the programmer. Choosing to use Python
rather than C restricts what you can do easily (but so would the
converse choice); choosing to use SQLite3 restricts your ability to
alter tables; choosing to use PyGTK forces you to include an external
dependency. But choosing to use Tkinter restricts *your users* to
BMP-only. That's a consideration that takes a bit more thought to
evaluate; how bad is it? You can decide on the cost of a UTF-8 string
type by figuring out how often you need to know about character
lengths, but how can you know the cost of a UCS-2 font renderer?

That's why I would be inclined to avoid Tkinter. Not because UCS-2 is
a fundamental deal-breaker, but because it's too hard to truly
evaluate the merits of the decision. Maybe external deps are just too
costly (like for Idle), or maybe you just detest all the other
options, and so maybe you'll end up coming back to Tk; but at the
initial evaluation phase, I would push for something else if at all
possible.

There's often some sort of problem with non-ASCII text in a program
that wasn't built for it. A lot of programs I use (including some that
I've written) have issues with RTL text - particularly, issues with
mixed RTL and LTR text on the same lines, which is a pretty hairy
problem. But at least if a program uses Python 3, it has a good chance
of getting most of it right. As you say, that's a huge advantage over
so many applications. :(

ChrisA

[toc] | [prev] | [next] | [standalone]

#89481

On Tuesday 28 April 2015 15:32, Chris Angelico wrote:

> On Tue, Apr 28, 2015 at 3:10 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Monday 27 April 2015 17:22, Chris Angelico wrote:
>>
>>> 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.
>>
>> I'm not really arguing with you, just giving a slightly difference of
>> emphasis...
>>
>> I don't think that failure to support the SMPs is a deal-breaker.
>> Obviously, if you specifically need some subset of Unicode in the SMPs,
>> say Phoenician, then it may be, but I'm just talking about general use.
>> Given the generally poor support for non-ASCII characters many
>> applications provide, any Unicode support is better than none.
> 
> I agree that it isn't _in itself_ a deal-breaker; it's a choice, but
> most choices restrict you, the programmer. Choosing to use Python
> rather than C restricts what you can do easily (but so would the
> converse choice); choosing to use SQLite3 restricts your ability to
> alter tables; choosing to use PyGTK forces you to include an external
> dependency. But choosing to use Tkinter restricts *your users* to
> BMP-only. That's a consideration that takes a bit more thought to
> evaluate; how bad is it? You can decide on the cost of a UTF-8 string
> type by figuring out how often you need to know about character
> lengths, but how can you know the cost of a UCS-2 font renderer?

On the other hand, you can use something like QT, except that judging from 
claims made by the KDE 4 developers, QT has a bunch of Unicode-related bugs 
which they refuse to fix (the one which keeps biting me is that the 
application will suddenly decide I am typing right-to-left, and everything I 
type shows up in redro gnorw eht. Only restarting the application fixes it.

I don't think that choosing UCS-2 only is any worse than any other 
application feature like "support only jpegs, not every obscure image format 
GIMP supports" or "choose to use floating point maths instead of some 
numeric type with unlimited precision". You are free to make whatever trade-
offs you like, and your users are free to use another application :-)



-- 
Steve

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web