Monday, January 5, 2009

It's Official: We're moving to Qt4!

SAYA-VE OFFICIAL ANNOUNCEMENT
=============================

We're disposing wxWidgets in favor of Qt4.

(End of announcement)

Unofficial comment by Rick.
===========================

I finally made up my mind. After an e-mail conversation with one of the VLC developers, I was told that they submitted quite a few bug reports to wxWidgets, and they were all dismissed. I was also told that wxWidgets was very difficult to work with, and recommended to work with GTK, QT, or anything _else_ (wow, is wxWidgets that bad?).

And my experience confirms it.

Now, I tried the QT4 dialog designer, and once you get the hang of it (you need to use a right-click menu to put all the controls in a layout, there's no standard button for that), it's a bliss. But is it compatible with GPLv3? Version 4.3.4 and up are. Hurray! :)

Sigh, so here goes YET ANOTHER month of changing existing code for arbitrary reasons. I'm lucky I had already adapted a lot of code from wxWidgets ;-).

I'll close this announcement with a famous quote:

"Chance favors the prepared mind".
Louis Pasteur

8 comments:

Vadi said...

That's a pity. wxWidgets is horrible, but Qt4 isn't much greater - Qt Designer will want you to tear your hair out after you've tried Glade.

rick_777 said...

Personally, I think it's matter of getting used to one or another designer. Considering that I don't use Glade and had to stay with wxFormBuilder, Qt Designer is a big upgrade ;-)

Oh. The reasons why I'm choosing Qt4 vs. wxWidgets are the following:

a) I need dockable windows. wxAUI simply doesn't cut it.

b) I need a consistent interface across platforms, and wxWidgets handling of bitmap buttons is just horrible.

c) I need more thread safety for Video playback.

d) Qt widgets are just prettier than the default wxWidgets ones.

See, it's not matter of what designer I use. But thanks for your concern :)

jech said...

I think it is a very good idea. Qt4 is IMHO really powerful and looks nice. I always prefer Qt applications and KDE.

Strangely enough as a programmer I use GTK+. But it's just because it's the first GUI toolkit I tried and it is simple enough for me to use. After trying to make a music player I found out that GTK+ has many troubles with multithreading in Windows. So Qt 4 is a much better choice for your project.

Btw. did you read my comment at Doom9 forum regarding the GUI? Dockable windows might be a good solution. But what about tabs? Will it be possible to place more widgets (windows) at one position with tabs to switch between them?

rick_777 said...

Jech: Sorry, I didn't see your post yet. But yes, I have planned to use docking windows, as you can see in the screenshots :)

One of the reasons I moved to Qt is because wxAUI is the only decent docking solution I could find for wxWidgets, and it's not user friendly. Users wouldn't like having to click on a specific spot of the window to be able to resize it.

Regarding tabs, I plan to use them for some windows (like sequences in the timeline). It all depends on how flexible Qt is for tabs/docks.

Thanks for the suggestion!

P.S. Mind linking to your doom9 post?

Vadim Zeitlin said...

[disclaimer: I'm a wxWidgets developer]

For me your post was really amazing to read as I personally had contacted VLC developers after their decision to switch to Qt asking why hadn't they ever contacted us (wx dev team) to discuss the issues they were having instead of concluding that they were impossible to fix (which was patently false BTW). I remain pretty upset that I hadn't received other feedback from them then other than mostly gratuitous insults and I find it's sad that they apparently continue to spread FUD about wxWidgets even several years afterwards.

So I'd just like to remark that it might be a better idea to ask about problems you have with wx on wx mailing list (and yes, I could have answered your points 1-4 if you had asked about them) instead of trusting technical expertise of folks whose basic opinion about wx was expressed to me as "it sucks and we're not wasting our time explaining to you why".

Anyhow, good luck with rewrite of your project in Qt!

rick_777 said...

Disclaimer: This is my personal opinion. Please don't turn this into a flame war.

Vadim: The VLC guy I contacted told me that his request was done via a series of e-mails. Now, I really don't know WHO was contacted, or the actual content of the e-mails.

But PLEASE, DO NOT blame the VLC devs, either. That information was given to me upon request and on a personal basis. If you want to blame someone, please blame me for making it public. I'm just trying to tell the world the reasons why I'm choosing Qt over wxWidgets. If they don't agree, well, it's their problem, not mine.

What is important here is that there are some issues still left unresolved in wxWidgets, and we can't afford them to be fixed in version xyz.

After trying Qt, I can say that some of the Issues I had to deal with in wxWidgets (like the application crashed because the wxWidgets reference counting was NOT thread safe, or the bitmap buttons behaving differently across platforms, or the docking system simply being horrible) do not exist in Qt. Call me an idiot if you want, but I need something that *just works*.

(flamebait: Perhaps if we had a decent UI designer available for free, that would have made me reconsider. But Qt designer is awesome, and you can't compete with that - but as I said, I don't want to turn this into a flamewar - this is a blog, not slashdot. /flamebait)

Now I'm not saying that Qt is the panacea: The moc precompiler is IMHO one of the worst ideas ever presented, and I'm having to do workarounds to solve that problem. The wxWidgets event model (regarding accessing an event by a numeric ID) is beautiful, and I'm using it for Saya.

But still, that doesn't solve the problem of having a non-skinnable, inconsistent and not-very-user-friendly GUI. For a project of this caliber, this is simply unacceptable. So, no, my decision wasn't biased by the opinion of the VLC devs. It might have been the last straw, or an eye opener: "there are other people having serious problems with wxWidgets, so I better reconsider my decision of staying with wx". Also, the slider widget in wx has a horrible hardwired behavior - and hardwired behaviors are a very powerful reason for me to move away.

Maybe in the future you'll release a wonderful, consistent, completely customizable and skinnable UI that uses all the powerful features of C++. But until that happens, I'm staying with Qt.

I'm sorry.

Sincerely,
Rick.

rick_777 said...

P.S. Thanks for wishing me luck :)

rick_777 said...

Well well, look at what we have here!

http://www.archivum.info/comp.soft-sys.wxwindows/2008-01/msg00341.html

Another very interesting discussion of multimedia handling and making the DC objects (actually all wxWidgets objects) thread-safe. And this discussion is from 2008. Well, I guess this confirms what I was trying to say and this is an example of what I've been trying to do and failing: Allocating a DC object on the stack and miserably failing because the destructor invokes the reference-counting function which is NOT thread-safe. This particular problem was actually what made me say: "Who designed this thing?" and depart from wxWidgets.

To put it simply, wxWidgets was not designed with multithreading in mind. Qt4 was (see http://www.crossplatform.ru/node/282 ).

But I won't waste any more time with this argument. There's so much code to convert, and I'm just beginning. Farewell!