The new Qt upgrade, 3.2beta features hundreds of enhancements and features that enable developers to build multiplatform applications. New features include:SQL support includes drivers for IBM’s DB2, Qt now supports all major script-based languages, including advanced languages such as Hindi and Bengali (screenshots). Qt 3.2 is also more efficient at font rendering. Qt Designer now has a menu editor that provides the ability to add, edit and remove menus and menu items directly in the menubar and the popup menu; and enhanced support for adding complex, custom container widgets (such as custom tab widgets). Qt Motif integration has been enhanced by additional documentation and code samples.
New Qt 3.2b Increases Support for Indic Languages
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
the future is here folks. lets all enjoy it
viva Mandrake
why should a UI toolkit contain database drivers?
Why does a language’s standard library include database drivers (Java, .NET)? Because it’s more convenient, and because Qt isn’t just a GUI library, but (like Java and .NET) a complete development framework.
yes – i like the Ui toolkit – i just don’t liek the feature creep. a “complete development environment” which evolves backwards from a UI toolkit is not in my opinion the right way to do it. java and .net didn’t grow backwards from the screen you look at. they grew up from the bits and bytes that flow around your cpu.
>a “complete development environment” which evolves backwards from a UI toolkit is not in my opinion the right way to do it.
Whose to say that? Trolltech is a commercial company. As such, they do whatever their customers ask. If their customers want a unified toolkit to do everything, and asked for this feature, then there is no reason for Trolltech not to implement it. If they pay for it, they will do it.
Qt isn’t a UI toolkit since Qt 2.0.
Instead it’s a Application Development Toolkit (and a damn good one at that!) Since Qt 3.0, things like database access, network, opengl, image access, etc.. have been in the form of plugins anyways.
Qt is nicely sized imho, unlike the behemoth API’s of Java, and to a certain extent, .NET too.
Both GTK (version two, through pango), and Windows have quite good support for Indic languages. This was the last major hole in internationalization in Qt, which has always been superb.
If only Qt didn’t need moc and used more modern C++ features, damn portability with really old UNIX compilers, why not just use the best technologies.
Is it backwards compatible with 3.x? or have trolltech finally come to a stage where by they don’t constantly need to break compatibility to move forward?
They should break compatibility if it brings important progress. They don’t have a user base big enough to really need to keep backwards compatibility, right now they just need to become known and show that their technologies are superior.
True, however, hopefully if they do break compatibility that it doesn’t break too much. It isn’t the fact of current applications but mainly for projects like KDE would are not only adding features but then have to contend with the ever changing of qt.
I just wrote a quite complex network app with QT. There is not a single line of code difference between windows and unix version.
The MOC that QT uses is there for compability with old, crappy compilers. Trolltech cant make QT depend on modern C++ features because they have paying customers that use these old crappy compilers. When they eventually upgrade and migrate to Linux Trolltech will be more than happy to drop the MOC system…
The reasons for Qt using moc – http://doc.trolltech.com/3.1/templates.html
ftp://ftp.trolltech.com/qt/source/README says:
“The Qt version 3.2 series is binary compatible with the 3.1.x series –
applications compiled for 3.1 will continue to run with 3.2.”
I think dportman had a good question. The answer is that people are not just wanting a crossplatform GUI. If you think about it, that’s just a small part of a crossplatform app. Trolltech probably would not sell much if they were all about the GUI.
So they provide a more complete “solution” so you can write a portable app in its little subset of c++. That suffices for a lot of users. Especially people who build robots or something that just need a nice interface for their customers without telling them what OS to run on their machines.
If QT is an all encompassing application development environment, why bother writing a KDE specific app?
Unfortunately, there is no free version of qt available for the Mac (ok, the X11 versions runs, but doesn’t support Aqua, of course).
Does anyone know if they have improved the real Mac OS X version since 3.0? The old screenshots on their web page still show version 3.0, which looks absolutely ugly (no antialiased fonts, no standard Aqua controls but only some kind of Aqua theme, which looks worse than Aqua themes for KDE or Gnome…)
I have never and probably will never touch kde, but for one thing, it costs money to use QT. It can be easily justified for many businesses (a programmer who could replicate its functionality would cost much more $), but no way that others could justify the expenditure.
http://www.trolltech.com/products/qt/pricing.html
Presumably KDE also does things like present a “shell,” supporting launching of programs, cut/paste and UI guidelines. These things are outside QT’s scope (I believe), whose programs are launched however the underlying systems launch their programs.
OT: Could we get rid of the Subject line?
If you think about it, they’re unnecessary and I swear to god I’ll start having subjects like “dkljfa;dkj”
I agree. Subjects don’t seem particularly useful.
Well, QT is a full application development toolkit. You will find that, like Java, it covers the basic range of functions required to produce most applications. In fact, with the database stuff, it goes further than Java’s foundation classes, which require separate database drivers.
Why should QT have these classes? Because it aims to be cross-platform, and it’s hard to produce a cross-platform app if you have to recode sections for different libraries (database drivers, again, a good example) or compilers on each platform you want to support. This way, you just rely on what QT provides.
Why program for the KDE instead of QT? Well, many applications don’t need anything more than QT, and that is why you will see Licq and others written in pure QT; however, KDE libraries offer a host of other features, such as DCOP, KParts, Kio Slaves and full network file transparency, which are really nice. Not only that, but if you are using a KDE desktop, being able to interface directly with components and integrate with existing applications (embedding KParts, or dealing with the user’s e-mail messages/contacts) can be a real benefit. These are the kind of things that you want to do at the user end, these days…
Some of the KDE elements are well beyond what a cross-platform toolkit needs, but what QT has, is all worthwhile. There have been mentions of bringing some of the KDE elements to QT, though, in basic forms. Personally, I’d love to see the network transparency added. It’s so nice
I prefer GTK2 over Qt, but I must agree with TrollTech that moc is a good way to achieve what they want. I’ve yet to see anybody make a credible argument against preprocessors, if they can make the programmers job easier with one, then good on them. Preprocessors are a fact of life for programmers.
It’s good that free software has such a great toolkit at its disposal. All we need to do now is make sure Qt and GTK properly interoperate so the end user is not exposed to the differences.
There are two reasons why Qt doesn’t use modern C++ features:
1) Many Qt classes, like QString and QList, predate the STL. It would be a lot of work to migrate all this code over to the STL.
2) Compiler compatibility. Not so much for crappy UNIX compilers (AIX and Solaris can both run GCC), but for crappy Windows compilers — namely Visual C++ 6.x. Since a real replacement (VS.NET 2003) just came out recently, most shops are still using 6.x, and are prisoners to its limitations.
Strongly off oopic but I disagree that subject lines are useless. I often just skip over the entire comments looking for interesting subjects (if there are many comments). So if you have something important or informative to say, please use a good subject line.
How about a compromize. Keep the functionality as it is today, but don’t display the subjectline if it’s empty (perhaps by merging the subject and author field)
I also vote to keep subject lines- when there are more than a handful of replies, I like to be able to make replies to people and read their counter-replies rather than just reading through tons of comments. Especially when people use the convention that has shown up of late- @nick. that way, I can just do a find on the page looking for refs to revaaron, finding replies to discuss.
I think the moc is pretty cool. Provides some neat features that a lot of C++ installations don’t have. sure, one could use RTTI in some cases, but I imagine that is more of a pain in the ass to use than Qt’s MOC. But what do I know, C++ has no place in my programming toolkit.
Maybe when Trolltech as a company grows bigger they can afford to produce their own C++ cross platform compiler (or frontend to gcc) and C++ dialect (Q++?) which supports the signal/slot mechanism without the need for moc. C++ itself started as a “preprocessed” language too, as C with classes from which C code was generated.
I wish they worked closer with the GTK people. GTK is LGPL afterall and could be used in a comercial product.