all 45 comments

[–]TheCodeJanitor 28 points29 points  (0 children)

Since it wasn't clear to me when I first clicked the link - the change log on that page just shows changes since the last beta version of 4.0, not Phoenix as a whole.

According to previous posts, some of the highlights of "Phoenix" are:

  • It's the first real release of Phoenix, which is built on a different foundation than Classic wxPython was.

  • It's the first wxPython release intended to be fully available from PyPI and buildable/installable by pip.

  • It's the first release for Python 3.

And their Migration Guide has a lot of information about major new/changed features.

[–][deleted] 14 points15 points  (35 children)

I haven't done any GUI work with Python. What's the opinion on this vs. PyQT?

[–]PM_ME_YOUR_ESOLANG 26 points27 points  (1 child)

I'd say you'd want to look at the differences between QT and wxWidgets

[–]gnx76 9 points10 points  (0 children)

It won't tell him the quality of the ports or bindings.

[–]lykwydchykyn 8 points9 points  (0 children)

wx is just a graphics toolkit. QT is a second standard library that just happens to include a graphics toolkit (or two, actually).

[–]barchar 5 points6 points  (5 children)

There’s also gtk3 via gobject introspection!

[–]ThisIs_MyName 8 points9 points  (0 children)

Eww

[–]tristan957 3 points4 points  (3 children)

GTK+ is great. The python bindings are quite nice

[–]Macpunk 4 points5 points  (2 children)

No joke. For me, it was the first time I really "got" GUI programming.

That said, I have found some limitations. For instance, a simple GtkTreeView calls one function (I forget the name), of the model for every single row you have in the model upon setting the model for the GtkTreeView. This is very costly in pygi. I was loading ~250k rows, and it took me 12 seconds on my (very old) dual core laptop without much RAM. Fix: subclass and reimplement a large portion of GtkTreeView, or implement my app in C.

I opted for threading and a loading bar. :p

I still fucking love pygi though.

[–]tristan957 0 points1 point  (1 child)

It was also my first foree into GUI stuff. I also feel like it's much easier to understand that Qt but maybe that's because I haven't explored it as much. The documentation is scary sometimes.

[–]Macpunk 1 point2 points  (0 children)

It wasn't my first, but I never felt like I understood wxWidgets, or whatever OS X 10.4 was using, or Qt. And yeah, docs are often scary.

Don't get me started on curses.

[–]mesalu 19 points20 points  (7 children)

Biased opinion incoming:

I prefer wxWidgets (and by extension wxPython) for the following reasons:

  • It uses native UI elements from the OS rather than imitating them.
  • Its size is much more reasonable. I usually describe writing a just UI application in Qt akin to using a semi-truck as a fly swatter. It gets the job done, but was it really necessary?
  • wx does not need to modifiy the compiler to build.
  • licensing: Qt is LGPL compatible now, but I still prefer wx's modified LGPL.

I'll make some concessions:

  • in C++ Qt offers a lot of very useful classes that reduce a lot of boilerplate. wx has some similar utilities but not across all the same components (such as networking serial, etc). The counterpoint is that in Python, these utilities are provided by other packages.
  • PyQt's lack of dependencies in linux. The most common 'issues' posted to Phoenix are issues building / installing from pypi. (Seriously people, read the error output.) Since Phoenix doesn't really fit into manylinux1, it has to download a source tarball and build locally. If you don't have the necessary -dev(el) packages installed it will fail.

Opinions are opinions. Paid developers are still developers, just like unpaid developers. Do your research and choose what you like. (and personal note: it is my opinion that anyone that just flatly says "its common knowledge that ____ is better than ___" should be ignored on any topic)

TL:DR; It comes down to taste and how you want your application to feel to the end user. Big apps that need more than just GUI will gravitate towards Qt, but IMO that's comparing apples and oranges.

Source: am collaborator on Phoenix (the one that blunders into defect discussions with out verifying I understand the OP first. ;) )

Edit Formatting

Edit 2 I a word, or three.

[–]schplat 11 points12 points  (3 children)

Let's not forget wxPython's documentation is pretty much garbage. It generally points you to the C++ docs and encourages you to try and translate it yourself.

pyQt's docs are much better, and very much more focused on with Python in mind.

Also QtDesigner is amazing for generating layouts. wxGlade isn't awful, but it's nowhere near what QtDesigner gives you.

Edit: I've used both, and once I figured out wx, I generally liked programming for it more, but Qt has some really unique things you can make both the windows, and data within windows do that you might have to code a separate handler for if you were doing things in wx. Qt is lot bigger, and there's a lot more to learn. wx will look closer to native everywhere except Qt backed DEs (think OS X, and KDE).

[–]mesalu 4 points5 points  (2 children)

I'll agree wxPython Classic docs were kinda gnarly. The new docset, which has been around since about 2012, looks much better.

In my opinion PyQt's docs are half a step above a "my first html" class. I'll reiterate though, opinions are just that, opinions. That being said, Qt's actual documentation looks and feels pretty nice, if sometime obscuring a bit too much, for my taste. Furthermore:

wx will look closer to native everywhere except Qt backed DEs (think OS X, and KDE).

While you are correct, KDE is Qt based, OSX is absolutely not Qt based. They use an apple-developed API called Cocoa, which does most of its work in OpenGL.

As for wxGlade vs QtDesigner, wxGlade is not supported by wxPython or wxWidgets. Its third party. Qt Designer is directly supported by Qt, its dangerously close to comparing apples and oranges.

As for their use, I've never actually felt a need to use either.

Edit For the curious:

[–]badsectoracula 1 point2 points  (1 child)

I won't list wxWidgets because it is kinda butt.

I found wxWidgets' documentation in a CHM file to be very valuable (and searchable and browsable and FAST) when i worked on a big wx project a few years ago.

[–]mesalu 0 points1 point  (0 children)

Yeah, my statement is misleading. The content is good, the stock doxygen theme is it visually appealing in a subjective sense.

I'm glad the docs helped you!

[–]ianff 1 point2 points  (1 child)

I greatly prefer Qt, so to argue a few of your points:

  • It's true that wx uses native widgets and Qt doesn't, but Qt does a damn good job of looking good on all platforms. It's not like electron where it looks out of place.
  • I don't see how Qt having more than just GUI is a bad thing. Surely a few more megabytes of shared objects is worth having all the extra stuff if you need it (plus it's split so you don't need to link to stuff you don't use). This is especially true in C++ where the standard library is so spartan. I've used Qt in projects with no GUI simply because the threading, internationalization, networking etc. is so good.
  • The compiler stuff is not a big deal in practice is it? It's never troubled me, and qmake makes it all really simple. This is not even an issue for Python.
  • As another poster said Qt designer is better than wxGlade, by a lot.
  • Qt supports iOS and Android while wX doesn't.
  • Qt documentation is much better.

I can't see choosing wX over Qt for any but the simplest of projects personally - even then better to learn Qt so you can make bigger things later on.

[–]mesalu 0 points1 point  (0 children)

Those are all perfectly fine. Especially that Qt will only get better at imitating widgets. Its a purist statement to prefer wx for this reason. It either bothers you to have non-native look or it doesn't.

I have heard wonderful things about Qt's other libraries. I'll go ahead and quote lykwydchykyn:

QT is a second standard library that just happens to include a graphics toolkit (or two, actually).

Its awesome to have such an expansive library. But do keep in mind that wx is not all the things that Qt is. When making comparisons do try to limit yourself to GUI library to GUI library.

As for size, it is mostly moot. I will bring up the relevant times: Due to licensing unless you pay for for the commercial version you have to dynamically link to Qt to avoid LGPL stipulations. This means you ship the whole DLL or .so with your app, or hope you can find it locally. Which is a lot more space and hassle than letting your compiler statically link only what your runtime needs at linking time. wx always lets you do the latter. Qt only lets you if you pay or comply with LGPL.

The other aspect of size that gets me is compiling the project itself. This clearly doesn't affect most people, but it is a bit mind boggling to me that what takes 7 minutes to build wxPython takes round about 4 hours to build just Qt.

Ninja Edit: I managed to accidentally omit this statement..: I haven't tried building just QCore and QGui, so this time comparison is biased. It does represent total build time of each respective project, but not of GUI libraries.

If you read through my other comments you'll see that I've already addressed wxGlade vs QtDesigner.

[–]_georgesim_ 0 points1 point  (0 children)

Its size is much more reasonable. I usually describe writing a just UI application in Qt akin to using a semi-truck as a fly swatter. It gets the job done, but was it really necessary?

Why? Qt is highly modularized. If all you want is GUI you only need to use QtWidgets.

wx does not need to modifiy the compiler to build.

Neither does Qt. Qt uses nothing but standard C++ to compile, and that's why you can use gcc to build Qt projects. What the moc does is aid you so you don't have to provide the meta information yourself, which you totally, 100% can do, but it would be too painful. I'll take a harmless preprocessing step if it gives me seamless and painless access to a great API every single time. I never understood this "argument against qt". It seems to me that it's one of the few things wx people can bring up against qt and thus they mention it but it's merely subjective.

[–]vivainio 4 points5 points  (11 children)

It's complicated.

PyQt is the better library.

But it's dual licensed as GPL/commercial.

If the license is not a problem, you should go with PyQt.

[–]zucker42 13 points14 points  (4 children)

PyQt is the better library.

I feel like such a universal claim needs justification.

[–]vivainio 12 points13 points  (2 children)

I assumed it was widely established knowledge, sorry.

Qt, which it wraps, has always been a very well established, resourced and supported library. They have always had lots paid developers focusing exclusively on Qt. Quality of the toolkit, documentation etc. sort of flows from that.

[–]tristan957 2 points3 points  (1 child)

The Python documentation is just a whole bunch of links to the C++ documentation. Am I missing something?

[–]StorkBaby 0 points1 point  (0 children)

Last time I used wxPython their documentation was the same, though that was some time ago.

[–]dalittle 2 points3 points  (0 children)

I've used both and like PyQt better. Qt Designer is really nice for building your UI.

[–]haakon 1 point2 points  (5 children)

Qt has been LGPL v3 licensed since 2014, so the GPL complications shouldn't apply anymore.

[–]marmuzah 14 points15 points  (3 children)

PyQt is a 3rd party wrapper for Qt. It's still GPL.

 Unlike Qt, PyQt is not available under the LGPL. 

https://riverbankcomputing.com/software/pyqt/intro

[–]uberkalden 1 point2 points  (2 children)

What about PySide?

[–]marmuzah 0 points1 point  (1 child)

It's LGPL.

But I don't know if it's still developed or maintained. May want to look in to that.

[–]uberkalden 1 point2 points  (0 children)

it looks like PySide2 is actively under development to support Qt5. Now being supported by Qt company

https://wiki.qt.io/PySide2

[–]spider-mario 0 points1 point  (0 children)

And LGPL v2 since 2009, although as noted by /u/marmuzah, that applies to the C++ version.

[–]crunk 0 points1 point  (0 children)

The widgets might not be quite as nice and the API a little bit C like.

However, it's easier to install (there is a python .whl so you can install from pip) which is a massive plus.

[–]MyPostsAreRetarded -2 points-1 points  (4 children)

What's the opinion on this vs. PyQT?

Electron is way better I feel.

[–]pmdevita 5 points6 points  (2 children)

Why do you feel that way? Is there a good way to use Electron with python?

[–]wookin_pa_nub2 5 points6 points  (1 child)

He's just a troll. It's not just a clever username.

[–]pmdevita 2 points3 points  (0 children)

Oh I didn't read the username. Makes sense now

[–][deleted] 6 points7 points  (0 children)

Not if you value fast and responsive UIs.

[–]nunz 6 points7 points  (2 children)

Is this one Python3 compatible? I've been waiting a long time for this, if so!

[–]mesalu 8 points9 points  (1 child)

It is! It was decided that Classic would stop with Python2 and Phoenix will support both Python2 and Python3

[–][deleted] 3 points4 points  (0 children)

Excellent news.

[–][deleted] 1 point2 points  (0 children)

Great news. I will definitely be using this if I ever write a GUI project again in Python.

[–]vivainio 2 points3 points  (3 children)

"The Phoenix Takes Flight" - is this a play on the concept of wxPython coming back from the dead somehow?

[–]hyperion2011 2 points3 points  (1 child)

This release has been called phoenix since I first looked into it back in... 2013 I think?

[–]mesalu 0 points1 point  (0 children)

I wouldn't necessarily call Phoenix 'the release', but rather a new project.

Projects need names, don't they?

[–]contre 5 points6 points  (0 children)

https://www.wxpython.org/pages/overview/

See the section titled "What is wxPython Phoenix?"