Qt being now released under LGPL, would you recommend it over wxWidgets?
Question:
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:
Answers:
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.
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.
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.
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).
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.
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:
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.
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.
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.
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).
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.