The new Qt 3.1 upgrade features hundreds of enhancements, TrollTech claims. Among the features are better ActiveX support, Motif integration, while for MacOSX you will find integration with the Appearance Manager, anti-aliased text drawing, and user settings. The Qt OpenGL support for OSX is also greatly improved, and uses the hardware-accelerated drivers. Also, Qt 3.1 offers more classes available for multi-threading, thereby optimizing performance. Elsewhere, GTKmm 1.3.21 for GTK+ 2 was released.
I just browsed their documentation and it seems that they
support a VERY limited number of animation and sound formats.
A shame really, but they do make it easy to talk to things like mpg123.
All in all a superb toolkit.
Naish
I’ve been using QT at work now for over 2 years on some highly interactive imaging software.
Good things:
The data structures they have are useable (stl anyone?)
The core libraries follow consistent conventions.
Fairly complete basic set of widgets.
Bad things:
lots of quirks in GUI layout
XML support is still half assed (no validation)
Data structures incomplete, bad for algorithmic work.
Continual increase in bloat with every release.
Add on modules sometimes don’t follow the naming conventions of the core.
Has anyone looked very heavily at Fox? http://fox-toolkit.org
I’ve been programming Qt for a number of years. No doubt, it’s the best GUI library out there. KDE, which relies on Qt, has proven that Qt is that good and successful.
Before using Qt, I’ve used MFC for some 4 years. Now looking back to MFC I think it’s so bad compared to Qt. MFC is nothing more than a bunch of wrappers around WIN32, while Qt is truely object-oriented, which makes it so easy to program and debug. Another big plus is Qt handles Unicode transparently across platform, including Windows 9X.
However, there is one possible problem with Qt on Windows platforms. Since Qt draws its own widgets instead of using existing ones(common controls) these widgets do not response correctly to 3rd party applications that want to talk to the Qt application using standard Windows message driven technology. Such applications are macro recorder/player, quality-assurance testing suite, or a scripting application. For example, let’s say you want the QA test program send a message to the Windows application that has a listbox to highlight the 3rd item. You can do so by sending an appropriate Windows message. However, the same method will fail if you try to communicate with an Qt application.
Qt has what they called Properties of the widgets that allow other Qt-based applications to communicate. But the bad news is that 3rd party applications mentioned above are not Qt-based. So if you’re writing a commercial application using Qt, don’t be surprised someday someone will complain that your application doesn’t work with their 3rd QA testing application.
Another downside is that if you run some theme manager like WindowBlinds at http://www.stardock.com your Qt application does not response to the current theme because Qt draws its own look. However, Qt should work with WinXP’s theme manager.
I haven’t try a Qt 3.0.5 app with TGT Soft’s Style XP theme manager (http://www.themexp.org/) yet…
Trolltech should make Qt apps use the KDE theme when running on KDE without having to be compiled/linked with some of the KDE libraries.
Regardless of the negative points mentioned Qt is still the best choice due to its professional quality and ease of use.
-Quang
>Trolltech should make Qt apps use the KDE theme when
>running on KDE without having to be compiled/linked with
>some of the KDE libraries.
Well, Qt apps use the theme you have configured. They do so under KDE, under Gnome, under Enlightment, everywhere. There are no KDE widget themes at all, only Qt widget themes. So Qt apps already can use “KDE themes” without the need to link against some KDE lib. This is true since Qt/KDE 3.0 and was the reason why for KDE 3.0 every widget style had to be reimplemented.
Just run ‘qtconfig’. In the style selector you should be able to select any installed ‘kde style’ (which in reality are just Qt styles). No Qt app need to be linked against any KDE lib to be able to use it.
Of course old Qt 2 apps are struck with the old Qt 2 widget styles.
> There are no KDE widget themes at all, only Qt widget themes.
I disagree. If you look in the KDE api documentation you’ll find a class called KStyle which inherits the QStyle class. This KStyle class adds a transparency engine (I believe) to the QStyle class as well as a few other handy tools. So, if a KDE widget style uses the KStyle class then I don’t think it can be used by any Qt application.
>>> Well, Qt apps use the theme you have configured. They do so under KDE, under Gnome, under Enlightment, everywhere. There are no KDE widget themes at all, only Qt widget themes. So Qt apps already can use “KDE themes” without the need to link against some KDE lib. This is true since Qt/KDE 3.0 and was the reason why for KDE 3.0 every widget style had to be reimplemented. <<<
Well, talk to the Trolltech folks and they’ll tell you. You miss the point. Try running an Qt app on a themed-KDE desktop like this:
http://www.kde-look.org/content/preview.php?file=48-1.png
and you’ll notice that the Qt app does not blend in at all.
—
Quang
call me crazy but i dont see what you mean, i find that the apps in that screenshot all had a consistent look.
Richard,
That screenshot does not have the Qt (non-KDE-based) app running. I meant if you ran it on such themed KDE desktop then you would see the Qt app not picking up the theme. It would look like a Windows app running on Linux.
As already mentioned by Anders:
“Of course old Qt 2 apps are struck with the old Qt 2 widget styles.”
Only Qt3 based apps share themes with KDE3, most apps (such as Opera etc.) are still using Qt2 and will not blend in.
Some Qt3 apps using KDE3 themes:
http://www.spanware.com/linkq/global.png
http://yammi.sourceforge.net/screenshot2.gif
To stay ontopic, anyone tried and compared the various GTK-wrappers, gtkmm, wxwindows and GCode? Anyone tried GCode at all?