Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I started learning a bit of python and would now like to toy around a bit with gui-building. Qt seems to be a good choice because of its cross-platformishness.
Now there seem to be two bindings available: PyQt by Riverbank Computing and PySide, originally developed by Nokia.
So which one should I choose? All I can find are two year old feature comparisons, but what differences are there nowadays?
Which one is easier to use, has more/better documentation? Are both still in active development?
Licensing isn't of much concern to me since I don't intend to write commercial applications.
Both toolkits are actively maintained, and by now more or less equal in features and quality. There are only few, rather unimportant differences.
Still, I'd recommend PySide for Python 2. It has a more reasonable API, mainly it doesn't expose Qt types, which have a direct equivalent in Python (e.g. QString, QList, etc.) or which are completely superfluous due to Python's dynamic nature, like QVariant. This avoids many tedious conversions to and from Qt types, and thus eases programming and avoids many errors.
PyQt also supports this modern API, and uses it by default for Python 3, but not for Python 2 to maintain backwards compatibility.
There is also the licensing difference. PySide is LGPL while PyQt is GPL. This could make a difference if you don't wish to make your project opensource. Although PyQt always has the propriety version available for a fairly reasonable price.
I tend to find the PySide documentation more intuitive. The API, in my opinion is slightly more Pythonic and the rate of bug fixes is quite impressive at the moment.
PyQt has the advantage of Python 3 support and incumbency. There is a lot more 3rd party documentation/tutorials for it.
I recently ported a significant code base (over 8,000 lines of code) from PyQt to PySide.
Right now I'd say PyQt is a much more mature, performant and stable project. I hit a number of bugs in PySide, and suspect that any big project will hit issues. Having said that, I reported a bug to the project and it was fixed and in a new release within a few weeks. I'm also having a problem where the app takes about 15 seconds to quit. I've not yet spent the time to find out why. However it's only a matter of time before there will be no reasons for choosing PyQt over PySide.
If you do decide to go with PyQt for now, make sure you use API v2 throughout. It is a better API, and will ease any future transition to PySide. Also if you do port, just follow the guidelines on the PySide wiki. Even for an 8+ kloc app consisting of about 20 source files it just took an afternoon.
Although they might have similar interface for Qt/C++ classes, their interface for Qt/C++ macros such as signal/slot/property are very different.
Porting one to another is not an easy job. It would be better to make the right decision at the very beginning.
Beyond the grammar/license differences, I just want to point out some deficiency of PyQt in language binding, which might be essential to write QML project in Python.
These differences finfally push me to PySide from PyQt.
qmlRegisterType
qmlRegisterType is essential to create runtime C++ binding with QML.
In PySide, it is part of PySide.QtDeclarative. And this works pretty well with Python.
In PyQt, qmlRegisterType does not exist. And I could not find an alternative approach.
I know some simple task could be done by setting QML context.
But if you really need runtime binding with qmlRegister and Q_INVOKABLE, I think PySide is the only choice at the moment.
Shiboken VS SIP
Both can wrap Qt/C++ into python plugin.
For Shiboken, I feel it is simpler and requires less coding.
Just create a typesystem xml including the NAME of classes you want to export, and that's all.
Shiboken does not require extra manual descriptions for the structure of the target classes.
For SIP, it would require more extra coding. We will have to create a SIP file that almost reimplements everything the C++ header.
It requires not only the NAME of the class, but also the DETAILS of what methods the target classes have.
If the C++ class is in good design using Pimp and we want to export all methods within it, SIP should provide a way of automatically export all class methods, which it cannot at the moment.
This would also add the burden for maintaining the consistency between the SIP and the C++ headers.
But I have to say that the documentation for Shiboken on Qt wiki is very bad and misleading.
Creating Python plugin with Shiboken on Windows do not necessarily require CMake at all.
generatorrunner is also not required.
I only use a windows cmd script to invoke shiboken, and a qmake pro for compiling the target plugin.
An important fact is that PyQt4 has two versions of its APIs for some things. Version 1 items are such things as using QString instead of unicode, and QVariant (basically just a wrapper, I believe - I've never actually done anything which uses it) instead the wrapped. Version 2, which can be enabled in Python 2 and is enabled in Python 3, is much better (though still unpythonic in many places - PySide is too, but it's getting distinctly better. There are still some remaining incompatibilities with them; PyQt4 has QtCore.pyqt(Signal|Slot|Property), PySide has QtCore.(Signal|Slot|Property).
For a project of my own, I decided that I wanted to support both with no changes to the code. I prefer PySide, but on Windows I distribute with PyQt4 as at present it's quite a bit smaller for distribution at present. My solution is to check for PySide and if it's there insert an import hook to redirect PyQt4 imports to PySide, or if it's not, fix up PyQt4 to work like it should.
The files used:
pyqt4pysideimporter.py
zip_imp.py (for py2exe support)
make_gui.py (my script for building .ui files and .qrc files with pyside or pyqt4 tools, and fixing the imports to be consistent; polls for file changes and rebuilds the changed - nothing high tech like inotify)
Then you just import pyqt4pysideimporter and pyqt4pysideimporter.autoselect() (as in main.py in that repository). And after that you can just import PyQt4.
Aside: it was also stated a few days ago on the PySide mailing list that they are planning on supporting Python 3 fully within the next few months.
I have a 20k line Python app that I unsuccessfully tried to convert to PySide.
Conversion is easy and most of the functionality works.
There are several methods that are not implemented because they are 'deprecated', so I had to fix those. That was OK.
On Windows, using PySide-1.1.2, the '==' operator is not implemented for many Qt objects. One workaround is to say: "if id(item1) == id(item2):".
The other observation is that PySide seemed noticeably slower. I did not isolate PySide as the cause of the slowness, but the problem went away when I reverted back to PyQt.
Lastly, as of now, the Android kit with PySide does not seem ready for prime time.
Related
I know in PythonQt I can access MOC'd QObject based classes in Python code and that python code can be executed from C++. Is it possible to do something similar using PyQt or is it intended to be used only to write Qt in Python?
I understand SIP is used to expose C/C++ code to Python but that doesn't seem to be as elegant as using the meta-object system.
I have never used PythonQt, but after a brief skim of the features, it seems that, in terms of conceptual emphasis, it really should have been called QtPython.
PyQt started life as a tool for prototyping Qt C++ applications in python. As a consequence, it was originally a very thin wrapper around the Qt library, which made it almost trivial to port Qt code from python to C++ and vice versa. And it still is quite easy to do this. But since PyQt4, the emphasis has shifted strongly towards making it easier to write Qt applications in Python; and with PyQt5, it has moved even further in that direction.
So PyQt is now intended purely for writing Qt applications in python (and the same goes for PySide). It does not provide any facility for executing python code within C++ (other than indirectly via virtual functions). If you need to expose third-party Qt classes to python, you would need to wrap them using Sip.
As for the meta-object system: PyQt does wrap QMetaObject and so forth, but there is not enough information in your question to know whether that would be of any use to you.
Features needed:
A framework, allowing me to build tab-based application with custom design (like in Hotot twitter client), keeping the native os window frame.
Compatible with Python.
My application will be running under Win/OsX/Linux/.
No Flash/Flex/AIR.
I also would like to ask if PySide does meet my requirements and is it worse or better than wxPython and Tkinter mentioned already?
Use Tkinter. It works on every platform that Python supports, is relatively easy to program in, looks pretty good on most platforms, and has the features you want. It's also built-in for most versions of Python, so your users (in many cases) will not have to install any external dependencies.
I find that Tkinter looks best on Mac OSX and Windows, and slightly outdated on some Gnome desktops. The most important feature, however, is that the API is extremely clean and easy to use and it is very lightweight. PyQt has a similar feature set, but, in my experience, its performance is significantly degraded when compared to Tkinter.
PySide is Nokia's Qt binding for Python. I'm not aware of what the differences are between it and PyQt. Ultimately, most GUI toolkits for Python are going to be cross platform and support the functionality you need. I suggest Tkinter because I feel it is the easiest and most pleasurable way to program GUI applications in Python.
I am the author of Hotot.
according to your requirements, the key for you to choose a framework is the UI framework should be able to access webview conveniently.
Hotot has several wrappers for different platforms. On Linux, we have both Qt and GTK version, on Windows, we provide a Qt version, on Mac, we have a Cocoa version, and of course we have a Chrome version. In a word, all they can easily access webkit.
PS: XULRunner is another good choice for native appearance.
Additionally to the advices given by other people, I suggest you to use PyQt which is a Python binding to Qt framework. It's widely used, cross-platform and feature-full.
Take a look at wxPython (based on wxWidgets). If you want to make it web-based, look into using Django.
Well, you mentioned PyHotOt, and it says (on its web site) that it uses pywebkitgtk, and PyGTK. PyGTK/PyWebKitGTK exists for windows. Did you check it out? I think OS X would be the weak link on GTK, but maybe it's pretty good too.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm thinking of making some kind of experimental IDE for digital hardware design. So I can't decide witch platform to choose.
I'm going to have text-editor with syntax highlighting, some vector graphics and lots of tabbed windows.
My goals:
1. to make GUI using as less custom components as possible.
2. to make it as cross-platform as possible
(I know already that CPython and Jython are cross-platform-friendly, but what about IronPython+Mono?)
So - the question is about GUI - what should I choose?
IronPython with Mono is cross platform - to whatever platforms supported by Mono, and for the feature set supported by Mono (which pretty much means Windows Forms is supported fairly well). Other options for GUI toolkits are available, however, which may provide better "cross platform" capabilities, or at least a better feel on non-Windows platforms.
CPython will depend on the GUI suite you choose. Personally, I've found CPython with PyQt to be the most usable, cross platform GUI option from Python. It's very powerful, feature-rich, and works quite well.
Jython will work, but I personally don't like the GUI options as much (this is a 100% personal preference, however).
I'd say that if cross-platform is a goal, forget IronPython. A lot of people hate the dependency hell it causes so it'll be too much work to get it up in running in some OSes/distributions. Jython will suffer this also, albeit to a lesser degree.
Well, Mono does not come with the base of most Linux distributions. It's not a terribly lightweight dependency either, and I think Java is considerably more likely for people to already have. Would you plan on using "Winforms" with Mono? If so, and you don't have experience with Winforms, read about what others have to say :-) The other .NET GUI toolkit is WPF, which unfortunately Mono has no plans to implement.
Jython would be better too, because you can use SWT, which renders native widgets and provides lots of layout possibilities easily. Or you can use Jython with Swing, or whatever else -- even AWT if you love ugliness.
I really like wxPython (which you can use with CPython, which is on most distros by default), because it renders good-looking native widgets in OSX, Windows and Linux (I've only seen the Gnome widgets in person). wxPython is by far the easiest to use GUI toolkit I've used -- even programatically (i.e. layout without Glade or similar). I've also used SWT, which I found quite nice, and Swing, which I personally don't really like the looks of, and Winforms, which was a nightmare to try to do even simple layouts with.
Here's a quick comparison of the existence of the interpreter/language runtime by OS
CPython
Windows - Probably not installed, and you'd have to make a non-python installer install it with your software :-P
Linux - Probably installed (Ubuntu, Gentoo and RedHat all have system tools that are written in Python and run on CPython)
Mac - Preinstalled on OSX
Jython
Windows - Probably installed at some point in my experience, though it doesn't come with
Linux - Probably installed, but more importantly nobody would hate you for depending on it like Mono
Mac - Preinstalled on OSX ("Mac OS X Leopard comes with J2SE 5.0 preinstalled, based on JDK 1.5.0_13_b05" -- Apple's site)
IronPython
Windows - Will probably run fine because I bet most people have at the very least .NET 2.0 if they have a recent version of Windows
Linux - Probably not installed -- the only application with which I've used Mono on Linux was Rasterbator, which worked well but I felt weird putting .NET on Linux
Mac - See above
I would choose a GUI toolkit first, since that will very much impact the user experience and overall difficulty (I would choose wxPython but SWT would be a close second) then consider the above as well maybe as a tiebreaker.
I faced this same question roughly a year ago. After looking at all the alternatives, I ended up with CPython and PyQt. IMO, Qt/PyQt is by far the best choice amongst all of the Python GUI toolkits. After hitting many bugs in wxPython I switched to PyQt and never looked back. Qt/PyQt are much more solid than the wx toolkits in my experience.
I use the exact same code base and build stand alone executables with PyInstaller for Windows and Py2App for the Mac (PyInstaller can be used for Linux as well). Because these builders embed the Python interpreter and all of the dependencies, it takes a lot of the hassle away. The only rub is that you'll need both a Windows and Mac to do the builds. Getting all of the configurations correct can be a pain too, but it's possible and time worth investing.
Take a look at comparable GUI's written in python/jython/ironpython. Look for programs that you like and find out what they use. I guess most if not all will be written in cpython + gtk or cpython + qt. I think all gui toolkits in python are cross platform.
Java is the most portable platform. Jython is written in 100% pure Java. 'Nuff said.
BTW I just switched a CPython/GTK project to Jython (trying to remove as much unmanaged code as possible), the only problem is that Jython is at 2.5 still, which kind of sucks when you're used to 2.6/2.7/3 :)
There are plenty of answers already, but I'd like to add one important thing - regardless of which library you learn, most of the principles will be the same when you move to another library.
I don't know about Qt, but for most graphics programs (in PyGTK or Tkinter) the best thing to do, as far as editing goes, is to use a PIL image (or something similar) to draw on and then draw that image on your canvas widget, otherwise you can lose pixel data if your window gets covered.
You may use Python 2.7 or 3.1 (CPython) with ttk (in Standart Library in 2.7, 3.1), ttk support themes (looks nice and very simple coding)
(1-st screen is text-editor with tabs and syntax highlighting) ttk screenshots
I need to decide on a GUI/Widget toolkit to use with Python for a new project. The target platforms will be Linux with KDE and Windows XP (and probably Vista). What Python GUI toolkit looks best and consistent with the native look and feel of the run time platform?
If possible, cite strengths and weaknesses of the suggested toolkit.
Thank you,
Luis
Python binding of Wx is very strong since at least one of the core developer is a python guy itself. WxWdgets is robust, time proven stable, mature, but also bit more than just GUI. Even is a lot is left out in WxPython - because Python itself offers that already - you might find that extra convenient for your project. Wx is the fastest especially on Win, because it lets render the OS and yes WxLicense is de facto LGPL. With XRC you have also a way like Glade to click you to a UI that you can reuse by different projects and languages. What is one major reason for me to use Wx is the fast and helping mailing list, never seen a flamewar, you get even often answers from core developers there, like the notorious vadim zeitlin++. The only thing con to Wx is the API that once grew out of MS MFC and has still its darker(unelegant) corners, but with every version you have some improvements on that as well.
QT done some nice stuff, especially warping the language but under python that don't count. They invented also a lot of extra widgets. In wx you have also combined, more complex widgets like e.g. for config dialog, but that goes not that far as in QT.
And you could of course use GTK. almost no difference under linux to Wx but a bit alien and slower under win. but also free.
For KDE and Windows, Qt is the best option. Qt is fine for Gnome/Windows too, but in that case you might prefer WxWidgets.
Qt bindings for python are here.
Remember that for closed source development you need a Qt license, plus a PyQt license.
For open source it should be free, but I'm not very familiar with the PyQt licensing.
Like others said, PyQt or wxPython... The technical difference between the two is more or less imaginary - it's a question of your comfort with the toolkit that matters, really.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am quite a heavy user of wxWidgets, partly because of licensing reasons.
How do you see the future of wxWidgets in prospect of the recent announcement of Qt now being released under LGPL?
Do you think wxwidget is still a good technical choice for new projects ? Or would you recommand adopting Qt, because it is going to be a de-facto standard.
I am also interested about the possible implications this will have on their bindings with the most common scripting languages (e.g. PyQt, wxPython, wxRuby). Why PyQt is so under-used when it has a professional grade designer and wxPython not?
Related:
https://stackoverflow.com/questions/443546/qt-goes-lgpl-on-windows-is-it-good-enough-to-use-instead-of-mfc
For those of us who are drawn to wxWidgets because it is the cross-platform library that uses native controls for proper look and feel the licensing change of Qt has little to no consequences.
Edit:
Regarding
Qt not having native controls but native drawing functions
let me quote the wxWidgets wiki page comparing toolkits:
Qt doesn't have true native ports like wxWidgets does. What we mean by this is that even though Qt draws them quite realistically, Qt draws its own widgets on each platform. It's worth mentioning though that Qt comes with special styles for Mac OS X and Windows XP and Vista that use native APIs (Appearance Manager on Mac OS X, UxTheme on Windows XP) for drawing standard widget primitives (e.g. scrollbars or buttons) exactly like any native application. Event handling, the resulting visual feedback and widget layout are always implemented by Qt.
I'm currently using pyqt at work and I find myself totally satisfied.
You have better documentation (IMHO), better event managing (signal-slot pattern is somehow more powerful than the old simple-callback style), and importing your custom widget in a graphical designer like qt-designer is far easier.
As far as I can tell qt-designer is more powerful than any wxpython counterpart, like Boa Constructor and pyGlade).
You also have great support for translating program's strings in different languages (better support than wxLocale at least, and you can use a tool like Qt-Linguist which is fully integrated in the qt system).
I'm using wxpython in some hobbistic works, but I'm still a noob there. I think its greater advantage over pyqt is to have a native look&feel on different platforms. This is a huge point if you are developing windows/linux applications, for example. Actually you could use "skins" to obtain a native look&feel with windows-qt applications but I have no idea on how to achieve that (sorry, I've never used qt on windows :D).
Honestly, I don't think that people will massively switch away from WxWidgets.
For python, there are PyQt bindings and WxPython bindings. Despite Qt being much more practical than WxWidgets, the majority of GUI python open source programs are written with WxWidgets. Since those programs are open source, the GPL vs LGPL did not matter that much in their choice of toolkit.
The same goes for Gtk. Many open source applications are written in Gtk, on windows, despite Gtk being very difficult to work with on windows. With Qt, those applications would be a lot easier to maintain on a cross platform basis, but it has not happened.
So, choice of toolkit is influenced by many parameters, licensing being only one of them.
I still don't understand why Qt is not more mainstream, because it's in my opinion the easiest and more practical GUI toolkit ever written.
Please note that, as of Jan 2009, while Qt 4.5 was to be available under LGPL, Riverbank Computing hadn't made any announcement about licensing for future versions of PyQt. PyQt is still only commercial/GPLv2/GPLv3.
As noted in comments for this answer, Nokia announced the LGPL-licensed PySide project in August 2009.
Qt is very comprehensive and high quality framework. I am sure that many new projects that would have used wxWidgets will now use LGPL Qt instead. But projects that are already using wxWidgets will no doubt continue to use wxWidgets rather than doing a massive re-write.
I chose wxPython for 2 main reasons:
Boa Constructor,
which is still a beta product, gives me unified control over 100% of the process, whereas PyQt indeed has better designer, but there's no connection between editing "event handlers".
My ideal IDE designs, creates events, let me edit just the functional code needed, and run; without "compiling UICs", without switching editors, without going into the command line.
While for Large scale applications it matters very little, my current domain is fast and small scale programs.
Licensing...
it doesn't matter right now, but it will once I start vending my stuff on small scale.
autocompletion inside event functional code doesn't seem to work in QTDesigner, for event code. I might be missing something, yet the "broken" process described above prevent it from being a RAD.
I was never able to setup Qt to cross compile. I remember seeing something from Trolltech saying that they don't officially support cross compilation, although I can't find it now.
There are many guides and such detailing how to get Qt to cross compile, so its possible (likely) that I was doing something wrong.
When choosing a framework, I recommend considering and testing out their cross compilation abilities.