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

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

Getting back into PyQt and not loving it.

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Getting back into PyQt and not loving it. Michael Torrie <torriem@gmail.com> - 2016-06-26 15:45 -0600
    Re: Getting back into PyQt and not loving it. llanitedave <llanitedave@birdandflower.com> - 2016-06-26 18:05 -0700
      Re: Getting back into PyQt and not loving it. Rustom Mody <rustompmody@gmail.com> - 2016-06-26 18:34 -0700
      Re: Getting back into PyQt and not loving it. MRAB <python@mrabarnett.plus.com> - 2016-06-27 03:12 +0100
        Re: Getting back into PyQt and not loving it. Mark Summerfield <list@qtrac.plus.com> - 2016-06-27 00:33 -0700
      Re: Getting back into PyQt and not loving it. Michael Torrie <torriem@gmail.com> - 2016-06-26 20:41 -0600
        Re: Getting back into PyQt and not loving it. John Ladasky <john_ladasky@sbcglobal.net> - 2016-06-26 23:15 -0700
          Re: Getting back into PyQt and not loving it. Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-26 23:44 -0700
            Re: Getting back into PyQt and not loving it. Michael Torrie <torriem@gmail.com> - 2016-06-27 09:11 -0600
          Re: Getting back into PyQt and not loving it. llanitedave <llanitedave@birdandflower.com> - 2016-06-27 10:23 -0700
      Re: Getting back into PyQt and not loving it. Ethan Furman <ethan@stoneleaf.us> - 2016-06-27 16:00 -0700
    Re: Getting back into PyQt and not loving it. lorenzo.gatti@gmail.com - 2016-06-27 00:27 -0700
    Re: Getting back into PyQt and not loving it. codewizard@gmail.com - 2016-06-27 13:14 -0700
      Re: Getting back into PyQt and not loving it. Michael Torrie <torriem@gmail.com> - 2016-06-27 18:26 -0600
      Re: Getting back into PyQt and not loving it. Sibylle Koczian <nulla.epistola@web.de> - 2016-07-02 12:08 +0200
      Re: Getting back into PyQt and not loving it. Sibylle Koczian <nulla.epistola@web.de> - 2016-07-02 12:08 +0200

#110541 — Getting back into PyQt and not loving it.

I'm starting to question the advice I gave not long ago to for new users
to consider the Qt toolkit with Python.

I just did a little project porting a simple graphical user interface
from GTK+ to Qt (PyQt4 for now as that's what I have installed).  For
the most part it worked out pretty well.  It's been a while since I used
PyQt or PySide, and I had forgotten what a horrid Python experience Qt
really is, at least in PyQt4.  Maybe the bindings for Qt5 are better...
I'll be working with them next as I convert my working code.

Qt's a fantastic toolkit, and the most mature of any of them, and the
most portable, but man the bindings are not Pythonic at all. PyQt does
not seem to hide the C++-isms at all from the programmer.  I am
constantly wrapping things up in Qt classes like QRect, QPoint, QSize,
etc, when really a python Tuple would have sufficed.  All the data
structures are wrapped in Qt C++ classes, so you end up writing what is
really idiomatic C++ code using Python syntax. Not the best way to code
Python!  Implementing signals in a class, too, reminds you strongly that
you're working with C++ as you have to construct their method signatures
using types that map back into C++.

[toc] | [next] | [standalone]

#110547

On Sunday, June 26, 2016 at 2:45:18 PM UTC-7, Michael Torrie wrote:
> I'm starting to question the advice I gave not long ago to for new users
> to consider the Qt toolkit with Python.
> 
> I just did a little project porting a simple graphical user interface
> from GTK+ to Qt (PyQt4 for now as that's what I have installed).  For
> the most part it worked out pretty well.  It's been a while since I used
> PyQt or PySide, and I had forgotten what a horrid Python experience Qt
> really is, at least in PyQt4.  Maybe the bindings for Qt5 are better...
> I'll be working with them next as I convert my working code.
> 
> Qt's a fantastic toolkit, and the most mature of any of them, and the
> most portable, but man the bindings are not Pythonic at all. PyQt does
> not seem to hide the C++-isms at all from the programmer.  I am
> constantly wrapping things up in Qt classes like QRect, QPoint, QSize,
> etc, when really a python Tuple would have sufficed.  All the data
> structures are wrapped in Qt C++ classes, so you end up writing what is
> really idiomatic C++ code using Python syntax. Not the best way to code
> Python!  Implementing signals in a class, too, reminds you strongly that
> you're working with C++ as you have to construct their method signatures
> using types that map back into C++.

Not sure that wxPython is really any different in that respect, and Tkinter doesn't feel Pythonic to me, either -- considering how it's Tk at heart.  So what's the alternative?  There really is no good Python-based GUI tool, and that's a shame.

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

#110548

On Monday, June 27, 2016 at 6:35:31 AM UTC+5:30, llanitedave wrote:
> So what's the alternative?  There really is no good Python-based GUI tool, and that's a shame.

The last time Ranting Rick made a big rant about this (saying wxpython should 
replace tkinter in core CPython) everyone took note of the rant
And missed the fact of the sux-state of GUI-in-python

Yes this is one big bus that python missed

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

#110549

On 2016-06-27 02:05, llanitedave wrote:
> On Sunday, June 26, 2016 at 2:45:18 PM UTC-7, Michael Torrie wrote:
>> I'm starting to question the advice I gave not long ago to for new users
>> to consider the Qt toolkit with Python.
>>
>> I just did a little project porting a simple graphical user interface
>> from GTK+ to Qt (PyQt4 for now as that's what I have installed).  For
>> the most part it worked out pretty well.  It's been a while since I used
>> PyQt or PySide, and I had forgotten what a horrid Python experience Qt
>> really is, at least in PyQt4.  Maybe the bindings for Qt5 are better...
>> I'll be working with them next as I convert my working code.
>>
>> Qt's a fantastic toolkit, and the most mature of any of them, and the
>> most portable, but man the bindings are not Pythonic at all. PyQt does
>> not seem to hide the C++-isms at all from the programmer.  I am
>> constantly wrapping things up in Qt classes like QRect, QPoint, QSize,
>> etc, when really a python Tuple would have sufficed.  All the data
>> structures are wrapped in Qt C++ classes, so you end up writing what is
>> really idiomatic C++ code using Python syntax. Not the best way to code
>> Python!  Implementing signals in a class, too, reminds you strongly that
>> you're working with C++ as you have to construct their method signatures
>> using types that map back into C++.
>
> Not sure that wxPython is really any different in that respect, and Tkinter doesn't feel Pythonic to me, either -- considering how it's Tk at heart.  So what's the alternative?  There really is no good Python-based GUI tool, and that's a shame.
>
Is it a problem with Tk itself or with the Python wrapper? Would it be 
better if we made a more Pythonic version of Tkinter, e.g. making 
Frame.title a property?

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

#110567

On Monday, June 27, 2016 at 3:12:34 AM UTC+1, MRAB wrote:
[snip]
> > Not sure that wxPython is really any different in that respect, and Tkinter doesn't feel Pythonic to me, either -- considering how it's Tk at heart.  So what's the alternative?  There really is no good Python-based GUI tool, and that's a shame.
> >
> Is it a problem with Tk itself or with the Python wrapper? Would it be 
> better if we made a more Pythonic version of Tkinter, e.g. making 
> Frame.title a property?

My main complaints about Tkinter are:

- Not very Pythonic.

- The event handling works very differently from other toolkits so it can be quite tricky to learn and get right.

- The bindings are incomplete (e.g., http://bugs.python.org/issue3405)

And for me there are show-stopping weaknesses.

- Show stopper #1: there is no nice way to create custom widgets. Compare with PySide, PyQt (& wxPython I believe) where you can inherit some "widget" base class and paint it however you like and do any event handling you like to get custom appearance and behaviour. Sure, you can do this with canvas as the base, but it seems like you have do do far more work in Tkinter than the other toolkits.

- Show stopper #2: there doesn't seem to be any way to create one line and multiline styled text editors (e.g., supporting bold, italic, underline, superscript, subscript, colour, font). The text widget can display all these (and more) but I haven't found any way to get it to be able to provide _editing_ of all these. (You can get it to do bold, italic, underline, and colour, but I certainly can't get these plus super- and sub-script and font support from Python. Nor is there any useful load/save in HTML or any other format.)

Hopefully people will point me to docs or examples to prove me wrong about these weaknesses:-)

Or better still, maybe the seemingly moribund PyGUI project could be revived or maybe someone will create bindings for libui or for IUP so that Python could have a lightweight GUI-only cross-platform library that had decent support for creating custom widgets in Python but left all non-GUI functionality to the rest of the Python ecosystem.

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

#110550

On 06/26/2016 07:05 PM, llanitedave wrote:
> Not sure that wxPython is really any different in that respect, and
> Tkinter doesn't feel Pythonic to me, either -- considering how it's
> Tk at heart.  So what's the alternative?  There really is no good
> Python-based GUI tool, and that's a shame.

Guess I kind of ended my email early.

Actually GTK+ is pretty nice to work with in Python.  The bindings feel
quite good and it's hard to tell where stuff is written in python and
where it's written in C.  The integration between Python data types and
the glib backend stuff is pretty seamless. I can't recall ever wrapping
up stuff in a GObject structure, and Python idioms work rather well
including iteration.  Try it out; it's pretty slick.

GTK+'s downsides are that though it's available on Windows and Mac,
those versions don't get as much love and without some real work don't
integrate very well.  Also GTK+ development seems to focus more on Gnome
than on general application development.

If GTK+ had first-class support on Windows and Mac, including native
themes and seamless UI integration (file and print dialogs), I'd say
GTK+ would be the only game in town for Python programmers.
Unfortunately, unless you're only concerned with Linux, GTK+ is probably
not going to be your choice.

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

#110562

On Sunday, June 26, 2016 at 7:41:17 PM UTC-7, Michael Torrie wrote:
> If GTK+ had first-class support on Windows and Mac, including native
> themes and seamless UI integration (file and print dialogs), I'd say
> GTK+ would be the only game in town for Python programmers.
> Unfortunately, unless you're only concerned with Linux, GTK+ is probably
> not going to be your choice.

Although I work almost exclusively in Linux, I've been teaching Python for several years as a sideline, and my students usually do not use Linux.  I insist on teaching my students Python 3.  Unless they're professionals who must work with legacy code (and, so far, none of them have been), I think I would be doing them a disservice to teach them Python 2.

I started with WxPython, but WxPython/Phoenix has been very slow to migrate to Python 3.  

Between the Py3 requirement and the need to work with all major OS's, I decided to learn PyQt and not GTK+.  

In my current day job, I'm developing an application on a Linux box, but I'll be handing it off to Windows users.  My choice of PyQt turned out to be the right one in that situation as well.

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

#110564

On Monday, June 27, 2016 at 6:16:01 PM UTC+12, John Ladasky wrote:

> Between the Py3 requirement and the need to work with all major OS's, I
> decided to learn PyQt and not GTK+.  

GTK+ is available for Python 3.

No doubt it will work on Windows as well, once Microsoft gets its Linux compatibility layer debugged...

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

#110595

On 06/27/2016 12:44 AM, Lawrence D’Oliveiro wrote:
> On Monday, June 27, 2016 at 6:16:01 PM UTC+12, John Ladasky wrote:
> 
>> Between the Py3 requirement and the need to work with all major OS's, I
>> decided to learn PyQt and not GTK+.  
> 
> GTK+ is available for Python 3.
>
> No doubt it will work on Windows as well, once Microsoft gets its Linux compatibility layer debugged...

But that's not a solution for John's target audience.  Nor for most
users, honestly.  The Linux layer is targeted towards Azure developers
mainly, and not intended to be an application support layer.

GTK+ is working natively on Windows, and the Python bindings work on
Windows. However GTK+ does not have nearly as good integration with the
Windows desktop in terms of look and feel as other solutions like Qt and
wxWidgets.  Running the Linux version of GTK+ inside of Windows' Linux
layer would not solve that problem!

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

#110603

On Sunday, June 26, 2016 at 11:16:01 PM UTC-7, John Ladasky wrote:
> On Sunday, June 26, 2016 at 7:41:17 PM UTC-7, Michael Torrie wrote:
> > If GTK+ had first-class support on Windows and Mac, including native
> > themes and seamless UI integration (file and print dialogs), I'd say
> > GTK+ would be the only game in town for Python programmers.
> > Unfortunately, unless you're only concerned with Linux, GTK+ is probably
> > not going to be your choice.
> 
> Although I work almost exclusively in Linux, I've been teaching Python for several years as a sideline, and my students usually do not use Linux.  I insist on teaching my students Python 3.  Unless they're professionals who must work with legacy code (and, so far, none of them have been), I think I would be doing them a disservice to teach them Python 2.
> 
> I started with WxPython, but WxPython/Phoenix has been very slow to migrate to Python 3.  
> 
> Between the Py3 requirement and the need to work with all major OS's, I decided to learn PyQt and not GTK+.  
> 
> In my current day job, I'm developing an application on a Linux box, but I'll be handing it off to Windows users.  My choice of PyQt turned out to be the right one in that situation as well.

I produced a couple of applications using wxPython 2.8 and Python 2.7, and I was happy with how they turned out, but since I moved to Python 3 I got tired of waiting for a Phoenix release that I felt comfortable with, so I've been learning PyQT lately. I do find that PyQt is more straightforward in many respects than wxPython, but the difference for me has always been how well organized and understandable the documentation is.  The PyQt examples seem very comprehensive, but the code is poorly commented and there are some quirks that are confusing me.   The original wxPython book was quite well put together and extremely helpful, and I miss having something like that for Qt.  I'm going through the eBook on PyQt4, but I'm not yet sure how well it will translate to PyQt5, which I'm trying to develop with.  I do think I'll stick with it, though.  Once I learn it I think it will serve me well.

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

#110617

On 06/26/2016 07:12 PM, MRAB wrote:

> Is it a problem with Tk itself or with the Python wrapper? Would it be
> better if we made a more Pythonic version of Tkinter, e.g. making
> Frame.title a property?

I would say it's the wrapper.

I appreciate all the work being done on tkinter lately, but it's still 
jarring trying to use the not-very-pythonic-at-all interface.

--
~Ethan~

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

#110566

PyGTK is obsolete and stopped at Python 2.7, while PyGObject for Windows is several versions behind (currently 3.18 vs 3.21) and it doesn't support Python 3.5. Game over for GTK+.

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

#110607

On Sunday, June 26, 2016 at 5:45:18 PM UTC-4, Michael Torrie wrote:
> 
> Qt's a fantastic toolkit, and the most mature of any of them, and the
> most portable, but man the bindings are not Pythonic at all.

Enaml feels pretty Pythonic to me:

https://github.com/nucleic/enaml

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

#110623

On 06/27/2016 02:14 PM, codewizard@gmail.com wrote:
> On Sunday, June 26, 2016 at 5:45:18 PM UTC-4, Michael Torrie wrote:
>>
>> Qt's a fantastic toolkit, and the most mature of any of them, and the
>> most portable, but man the bindings are not Pythonic at all.
> 
> Enaml feels pretty Pythonic to me:
> 
> https://github.com/nucleic/enaml

Cool. I'll check it out.

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

#110952

Am 27.06.2016 um 22:14 schrieb codewizard@gmail.com:
> On Sunday, June 26, 2016 at 5:45:18 PM UTC-4, Michael Torrie wrote:
>>
>> Qt's a fantastic toolkit, and the most mature of any of them, and the
>> most portable, but man the bindings are not Pythonic at all.
>
> Enaml feels pretty Pythonic to me:
>
> https://github.com/nucleic/enaml
>
But:

Enaml is a Python framework and requires a supported Python runtime. 
Enaml currently supports Python 2.6 and Python 2.7. Python 3.x support 
may be added in the future, but is not currently a high priority item.

http://nucleic.github.io/enaml/docs/get_started/installation.html

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

#110953

Am 27.06.2016 um 22:14 schrieb codewizard@gmail.com:
> On Sunday, June 26, 2016 at 5:45:18 PM UTC-4, Michael Torrie wrote:
>>
>> Qt's a fantastic toolkit, and the most mature of any of them, and the
>> most portable, but man the bindings are not Pythonic at all.
>
> Enaml feels pretty Pythonic to me:
>
> https://github.com/nucleic/enaml
>
But:

Enaml is a Python framework and requires a supported Python runtime. 
Enaml currently supports Python 2.6 and Python 2.7. Python 3.x support 
may be added in the future, but is not currently a high priority item.

http://nucleic.github.io/enaml/docs/get_started/installation.html

[toc] | [prev] | [standalone]

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

csiph-web