views:

2631

answers:

7

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:

http://stackoverflow.com/questions/443546/qt-goes-lgpl-on-windows-is-it-good-enough-to-use-instead-of-mfc

+6  A: 

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.

Bluebird75
Licensing do count a lot! If you start writing a software, you won't necessarily think open source it right from the start. So you'll chose to use LGPL libs.This is why Qt was not mainstream, and why most open source python programs use wxpython even if there is no professional grade designer for it
Mapad
Perhaps the soon to be released Qt 4.5 will answer this problem. It will have an LGPL licensing option.
+3  A: 

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.

Andy Brice
yep. same for our company. they are going to use Qt. starting with arounud version 4, Qt can also use native widgets i read. so it's not too bad looking :)
Johannes Schaub - litb
+8  A: 

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.

akaihola
True. But still this is a big change to have only to pay for PyQT (£350), compared to a former extra $4,000 for QT.
Mapad
Now there is PySide : http://www.pyside.org/
dugres
+5  A: 

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 funtions

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 (Appeareance 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.

mghie
I thought Qt used the native look and has done for a while?
Rob
AFAIU they only use the native drawing functions, but implement the controls on their own. That may give a near-native look, but will never give a native feel. It is also bound to break on newer OS versions.
mghie
Windows has very few true native controls. The only platform with a significant amount of native controls is Mac. And wxWidgets looks and feels shit there. So I find your opinion lacking at best.
Max Howell
I don't know what peculiar meaning the word native has for you - but let's not get into that. The look and feel of wxWidgets on the Mac is indeed lacking, but the code in SVN trunk is based on Cocoa instead of Carbon, so that's something that's going to improve.
mghie
@mghie please elaborate on Qt not having native controls but native drawing funtions!
andho
Qt can use native Cocoa widgets now, so wx doesn't really have a lead there.
ephemient
@ephemient: What about Windows API controls and GTK widgets? And could you add a link to more information regarding this?
mghie
I don't know about Windows, but Qt/X11 now includes QGtkStyle, which uses Gtk+ for drawing all elements (and colors and icons). http://doc.trolltech.com/4.5/qmaccocoaviewcontainer.html http://doc.trolltech.com/4.5/qmacnativewidget.html http://doc.trolltech.com/4.5/qgtkstyle.html
ephemient
@ephemient: But that's only look, not look and feel. This is not using native widgets, this is only using the standard system facilities for drawing non-native widgets in native style. Not what I would call "use native widgets".
mghie
Also, wrapping native widgets of *one* platform isn't really a cross-platform solution, is it? One would need to do this for all platforms then with conditional compilation, to get something that wxWidgets provides OOTB.
mghie
There's not really any such thing as "native" on X11 -- everybody draws their own. Note that QGtkStyle uses Gtk+ dialogs too, instead of Qt dialogs. On Mac, the default has been that Qt draws its own widgets with the help of http://developer.apple.com/mac/library/releasenotes/Carbon/HIToolbox.html but there is http://labs.trolltech.com/blogs/2009/04/17/mac-widget-style-addons/ work in progress to draw some widgets entirely with Cocoa.
ephemient
I think the Carbon port for wxPython is coming in the 2.9 series, which should release this year. As I understand PyQt, you still have to pay something since it's still owned by Riverbank, not Nokia. And Pyside, the Nokia equivalent is still beta and has no Windows port.
Mike Driscoll
+9  A: 

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).

happy_emi
+1  A: 

I chose wxPython for 2 main reasons:

  1. 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.

  1. Licensing... it doesn't matter right now, but it will once I start vending my stuff on small scale.

  2. 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.

Berry Tsakala
But the down side of Boa Constructor (and it's quite a big down) is that when you update wxPython you have to manual update all the widgets since Boa parses the Python source (rather than store the widgets and properties separately). It is a great (free) application though. Try ERIC with PyQt...
Nick
A: 

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.

Matthew
Really? What do you mean by cross compile? Do you mean compile for various target archs on one specific arch? Or do you mean compiling the code on their respective archs?
sims
@ sims Compiling on system for many. I remember reading something from Trolltech saying such, but can't find it now.Regardless there is a lot of documentation online on how to cross compile with Qt.
Matthew