Best GUI for Python

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Cecil Westerhof
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


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Steven D'Aprano-11
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



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Cecil Westerhof
In reply to this post by Cecil Westerhof
Op Sunday 26 Apr 2015 15:02 CEST schreef Cecil Westerhof:

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

It is important to tell which version of Python I use, because
wxPython does not work with Python 3.

At the moment I am still working with Python 2.7.8 and am not planning
to update to 3 in the near future.

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


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Cecil Westerhof
In reply to this post by Steven D'Aprano-11
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


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Mark Lawrence
In reply to this post by Cecil Westerhof
On 26/04/2015 17:16, Cecil Westerhof wrote:

> Op Sunday 26 Apr 2015 15:02 CEST schreef Cecil Westerhof:
>
>> 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?
>
> It is important to tell which version of Python I use, because
> wxPython does not work with Python 3.
>

The development version of wxpython for Python 3 here
http://wxpython.org/Phoenix/snapshot-builds/

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

Mark Lawrence



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Gary Herron-2
In reply to this post by Cecil Westerhof
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



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Cecil Westerhof
In reply to this post by Cecil Westerhof
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


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

mr.smittye@gmail.com

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


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Gary Herron-3
In reply to this post by Cecil Westerhof
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.


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Ben Finney-10
In reply to this post by Steven D'Aprano-11
Steven D'Aprano <steve+comp.lang.python at 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



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Chris Angelico
On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney <ben+python at benfinney.id.au> wrote:

> Steven D'Aprano <steve+comp.lang.python at 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


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Christian Gollwitzer
In reply to this post by Ben Finney-10
Am 27.04.15 um 01:06 schrieb Chris Angelico:
> On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney <ben+python at 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



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Steven D'Aprano-11
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



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Chris Angelico
In reply to this post by Christian Gollwitzer
On Mon, Apr 27, 2015 at 4:55 PM, Christian Gollwitzer <auriocus at 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 at 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


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Christian Gollwitzer
In reply to this post by Steven D'Aprano-11
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




Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Steven D'Aprano-11
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



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Grant Edwards-7
In reply to this post by Steven D'Aprano-11
On 2015-04-26, Ben Finney <ben+python at benfinney.id.au> wrote:

> Steven D'Aprano <steve+comp.lang.python at 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!


Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Christian Gollwitzer
Am 27.04.15 um 19:02 schrieb Grant Edwards:

> On 2015-04-26, Ben Finney <ben+python at benfinney.id.au> wrote:
>> Steven D'Aprano <steve+comp.lang.python at 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

>



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Steven D'Aprano-11
In reply to this post by Christian Gollwitzer
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



Reply | Threaded
Open this post in threaded view
|

Best GUI for Python

Chris Angelico
On Tue, Apr 28, 2015 at 3:10 PM, Steven D'Aprano
<steve+comp.lang.python at 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


12