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 2 of 2 — ← Prev page 1 [2]

#89483

On Tue, Apr 28, 2015 at 4:43 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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 :-)

True, although supporting only one image format can be worked around
by converting your images. You can't just convert your UCS-4 data into
UCS-2.

ChrisA

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

#89487

On Tuesday 28 April 2015 16:59, Chris Angelico wrote:

> On Tue, Apr 28, 2015 at 4:43 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> 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 :-)
> 
> True, although supporting only one image format can be worked around
> by converting your images. You can't just convert your UCS-4 data into
> UCS-2.

Of course \u0079\x6f&75; can :-)




-- 
Steve

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

#89489

Am 28.04.15 um 09:54 schrieb Steven D'Aprano:
> On Tuesday 28 April 2015 16:59, Chris Angelico wrote:
>
>> On Tue, Apr 28, 2015 at 4:43 PM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> 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 :-)
>>
>> True, although supporting only one image format can be worked around
>> by converting your images. You can't just convert your UCS-4 data into
>> UCS-2.
>
> Of course \u0079\x6f&75; can :-)
>

Lossy data compression ;)

	Christian

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

#89491

On Tue, Apr 28, 2015 at 5:54 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tuesday 28 April 2015 16:59, Chris Angelico wrote:
>
>> On Tue, Apr 28, 2015 at 4:43 PM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> 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 :-)
>>
>> True, although supporting only one image format can be worked around
>> by converting your images. You can't just convert your UCS-4 data into
>> UCS-2.
>
> Of course \u0079\x6f&75; can :-)

That's an encoding, not a conversion :)

ChrisA

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

#89510

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

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

#89525

See also

https://groups.google.com/forum/#!topic/wxpython-users/PuGhO-dmmm8

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

#89532

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

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

#89422

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

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

#89424

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

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

#89451

Le dimanche 26 avril 2015 15:39:36 UTC+2, Cecil Westerhof a écrit :
> 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

There is none. tkinter, wxPython/wxPhoenix, Qt derivatives
pyside, PyQt* are all not, or no more, working. Two reasons
among plenty of others, Unicode,  SMP *and* BMP [*], and
the characters handling.

For a serious work - I have no, very little, experience with
them -, the single way to work properly is to use Jython or
the future/next IronPython. The reason is that "Python" in
those cases, is embracing or build for java or .NET framework.
The opposite of a wrapper around Qt, wxWidgets, "tcl", ...
toolkit.

[*] Even Python in LibreOffice fails. I need 30 seconds
to show it.

jmf

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

#89498

On 2015-04-26, Cecil Westerhof <Cecil@decebal.nl> 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?
>

For cross-platform work, I think it comes down to wx or Qt.  I've used
them on Windows, Mac and Linux.  Qt has the more polished and
consistent API, and is more popular with the big scientific Python
distros. wx has the most liberal license, and I think having to deal
with only one Python binding is somewhat an advantage.  I've gone back
and forth between them, and could probably live with either one.

Gtk is also worth looking at if you only care about Linux.

Dave Cook

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web