Nokia today announced the availability of version 4.5 of the Qt cross-platform application and UI framework. It also introduced Qt Creator, a new lightweight cross-platform IDE. Qt 4.5 and Qt Creator combined comprises the Qt SDK, an easy to install package that will let developers create applications quickly and easily. “Qt 4.5 is setting the benchmark for application development,” said Benoit Schillings, Chief Technologist, Qt Software, Nokia (and for those who remember, one of the original BeOS developers). It’s also the first release of Qt under the LGPL.
Qt 4.5 includes several new features, but sees the greatest improvement via a concerted effort to increase performance across the entire framework. Significant performance enhancements were made to the graphics system, data handling, and the web engine. These improvements result in an appreciable performance increase in Qt-based applications.
Qt 4.5 also improves integration with the WebKit web rendering engine which will blend web and native content into a richer user experience. This includes:
- Netscape Plugin API support; allowing Qt applications to load Flash (such as the YouTube player)
- More advanced web UI effects, including animations, transformations and zooming
- New JavaScript engine for better performance
Qt 4.5 has also been ported to Apple’s Cocoa framework. Previously Qt supported only the Carbon framework, but with Qt 4.5, Qt can now support both. This means developers can create applications that support 32 or 64 bit, Intel or PowerPC Mac binaries from a single source.
Developers can now download version 1.0 of Qt Creator, a lightweight cross-platform IDE for Qt development. Qt Creator has been designed to deliver two key benefits: it provides the first IDE designed specifically for cross-platform development; and it enables developers that are new to the Qt framework to get up and running more quickly.
Qt Creator includes an efficient tool set for creating and testing Qt-based applications, including:
- An advanced C++ code editor
- Context sensitive help system
- Visual debugger
- Source code management
- Project and build management tools.
This sums it up fairly well: http://aseigo.blogspot.com/2008/11/qt-creator-kdevelop.html
What I see is qtcreator is nice, but it’s not enough. The integration and richness in tools and project handling of kdevelop is much better, even with its faults, and I don’t see what could make me stop using it.
*sigh*
Why does everybody compare Qt-Creator with kdevelop ?
Qt-Creator was never designed to be a kdevelop replacement, it was just an IDE to do especially C++ development with Qt and their build system qmake.
Since kdevelop cannot parse my qmake files I use Qt-Creator and I am quite happy with this IDE.
btw: Your link is a little bit outdated: In the meantime Qt-Creator added support for svn, git and cmake.
Edited 2009-03-03 13:33 UTC
Because they are both IDEs?
kdevelop doesn’t need to parse your qmake files – you can easily import the project with “custom buildsystem”.
The fact is that kdevelop and qmake almost completely overlap – kdevelop is burdened by kde 3.x dependency (mostly a problem with windows) and the baroque UI, and qt creator by its relative immaturity (kdevelop is pretty much rock solid now).
They both have different goals, that’s why you should not compare them. Qt-Creator is minimalistic and special purpose, and the developers said it themselves: They don’t want to compete with bigger solutions like eclipse or kdevelop.
I work on a multi platform project with 56 subprojects and unit tests with over 1000 files. As long as I had a working qmake project manager I could add/remove files out of kdevelop and select the project to debug and so on. I cannot not do that as comfortable with a custom buildsystem.
I choose my tools with the lowest work overhead and in the moment that is Qt-Creator for Linux/MacOSX and VC2008 + VisualAssist on Windows.
But it just doesn’t seem too hard competing with other C++ ide’s, since qtc already has 1) intellisense, 2) gdb integration, 3) context based code navigation. If what remains is just parsing some project files to determine what source files are part of the project, it’s not a stretch to assume that some qt creator fan will want to add that stuff to the app (it’s open source after all).
Ditto. ATM it’s kscope & gdb (because of what the environment dictates – a non-ide seems to be easiest to manage in scratchbox environment). I’m keenly following where the next gen IDEs will take us (qt creator broadening its scope, kdevelop4 coming out, CDT maturing up). Good times ahead – a while ago kdevelop was the only one worth using at all.
For those of us stuck in Windows land is a very welcome IDE.
Now I can very easily set up a QT based development environment with free tools.
The previous solutions of QT + (whatever IDE) + mingw was a bit cumbersome to set up.
But then, the goal of Qt Creator wasn’t to make you or anyone else stop using kdevelop (which I use myself, too, KDevelop4 is simply amazing), but to give people who now use an editor+command line combination something that’s as fast and comfortable to use but that makes debugging easier.
I’m not convinced that it does, but I use it on OSX and Windows where KDevelop doesn’t yet run, and it’s a fine editor with some nice and handy touches.
I haven’t managed to make it build and debug my projects, though 🙂
(Oh, and what I particularly like about Qt Creator is that it is a nice, big example of how to structure a Qt application with plugins and everything. It’s very instructive to browse through its source.)
Just to clarify: I’m using cmake, which while supported, isn’t really done yet, and besides, I’m using cmake with visual c++ on Windows and on OSX, and cmake support for those platforms aren’t tested yet.
And when I’m working on Unix, I’m working on KOffice, and a CMake project of the magnitude of KOffice really stretches any IDE (but Qt Creator loads the KOffice project from the CMakeLists.txt files _perfectly_, so it’s a very useful IDE for my purposes anyway.)
CMake has run with VC++ for a long time on Windows. OSX, don’t know; but Windows definately.
I know, and that’s why we use cmake. It’s just that the cmake integration in Qt Creator doesn’t support that yet — the generator for unix makefiles is hard-coded in Qt Creator, for now.
Note I haven’t tested qt creator yet, so I have no idea how good it actually is. That being said…
Qt creator has one big potential strength and that is cross platform development. Doing cross platform Qt development with the free tools has never been trivial. If this new IDE will let me easily open, work on and compile the same project on Linux, Windows and OS X with minimum fiddling then I’m interested.
True. But besides that it is also a very nice IDE. I have been using Qt Creator since the first betas. I have tried KDevelop in the past, it was to messy for me (coming from plain Makefiles + vi). I though Eclipse was ok environment-wise, but unfortunately it was to slow for me (I don’t want to wait a few seconds for completion). So far, Qt Creator has been great for me. It is clean, feels slightly minimalistic, but has all the nice stuff: completion, quick search(/replace), look ups, etc.
Edited 2009-03-03 21:28 UTC
Has anyone found a reliable source download location yet? I can’t connect to their Norwegian FTP site, and the mirrors either have no copy of Qt 4.5 or a broken one (e.g. heanet.ie). I’m looking for the X11 version.
Try;
http://dist.trolltech.com/torrents/
I’m using the RC on my Ubuntu Jaunty and I must say the Gtk integration is flawless! With it, Arora looks more a Gnome application then Firefox! Very nice work
Now I don’t have anymore the dilemma of liking both Gnome and Qt4
Yer, it’s just a pity that the GTK and Gnome guys aren’t receptive to that kind of integration themselves.
Edited 2009-03-04 12:37 UTC
Waiting to see if PyQt will be LGPL so I will know whether to throw my book away and wait for someone else to create LGPL QT bindings for python.
I think you may be waiting a long time. If there is already a high quality GPL’d version of a Python binding for Qt, why would anyone want to spend entire man-years redoing a new one with a slightly different license?
The difference is substantial. It means the difference between being able to create commercial closed source apps and not.
If he doesn’t LGPL it someone else will create an LGPL’d binding.
Not true. Riverbank offers commercial licenses of PyQt, so you can write closed source commercial apps with it just fine. You just can’t do it for free.
Highly unlikely, but anything is possible.
I’m not talking about the difference from the point of view of someone using the bindings, I’m talking about the point of view of this person who you expect to develop the bindings. You really believe someone is going to donate 1-2 years of their time in order that you don’t have to pay 350 pounds or so for a commercial PyQt license? What’s in it for them?
I think that vendor does no want to allow you and the others to use their work in order to create proprietary applications. They probably have some interest in doing so. Perhaps they want to retain an advantage over the other proprietary developers. They have every right to do that.
I think you’re overstating it a bit. Riverbank is mostly a one-man operation. I don’t want to understate the work involved, but I don’t think it would amount to man-years to duplicate if someone or some group was intent on doing so.
Riverbank has every right to continue with the GPL/commercial model that Qt had. PyQt is a fine, and popular, product.
BUT, I suspect the LGPL announcement took the wind out of their sails. Compared to the license fee for Qt, a PyQt commerical license was incremental for commercial development. While it is still nominal in the overall scheme of things, at least in terms of commercial developers that measure value by ROI rather than absolute cost, it now stands out amongst an LGPL’d Qt field with LGPL’d bindings for other languages.
I don’t begrudge Riverbank’s model, all the more power to them for the time and effort they’ve extended over the years, I just suspect that they’re going to have to figure out how to adapt to the new licensing scheme while still remaining viable. Nature abhors a vacuum, and I’d be surprised if an alternative didn’t spring up otherwise.
I think you’re overstating it a bit. Riverbank is mostly a one-man operation. I don’t want to understate the work involved, but I don’t think it would amount to man-years to duplicate if someone or some group was intent on doing so.
You’re welcome to believe what you like about the man effort involved in writing high quality complete bindings for the Qt apis.
I speak as the developer of several Qt language bindings (QtJava, QtRuby and Qyoto C#), and should have some idea of how much work is involved. For instance, I’ve been working on QtRuby for over five years, including 2 years full time, and I can tell you that I still have a big todo list.
There are python bindings based on PyQt for KDE too, and any replacement project would need to replace that work too, while managing to keep the community on their side.
It won’t happen unless Nokia (or a similarly sized company) takes over Riverbank Computing as well as Trolltech. Riverbank, like Trolltech, is a small software company which depends on selling commercial licences.
That is pure speculation. Riverbank has neither accepted nor declined the requests to go LGPL at some point.
Luckily, the commercial license for full setup is much cheaper now that you don’t need to buy Qt library in addition to PyQt anymore.
I liked the IDE, but still hate the actual form designer…its really chaotic to use compared with the VS.NET one.
I can see how the upcoming KDE 4.3 would gain from performance improvements in Qt4.5 (which is very welcome because KDE 4.2 is already a good performer), but what about the KDE 3.5.x series? What version of Qt does it, or can it, use? AFAIK there was “breakage” between Qt3.x and Qt4, and that this in part was a major reason for the whole KDE3/KDE4 rewrite.
AFAIK though, KDE3 applications can be run on a KDE4 desktop … but do they have to be re-compiled against the newer Qt libraries, or some “translation” libraries, in order to do so? Or is it somehow possible to use Qt4.5 as the “heart” of newer versions of KDE3?
Will KDE3 see any benefit at all from Qt4.5 and the LGPL licensing of this Qt version and later, or does this announcement effectively mark the start of the “putting out to pasture” of the KDE3 desktop?
No. A KDE3 application uses Qt3, not Qt4. It is impossible, except through porting, that is, changing the source code, to compile a KDE3 application against Qt4. Note that in addition to porting the application code, you will also have to port the library code of KDE3, and then you will end up with… KDE4.
It’s totally simple:
KDE 1.x — Qt 1.x
KDE 2.x — Qt 2.x
KDE 3.x — Qt 3.x
KDE 4.x — Qt 4.x
where the x doesn’t need to the same value on both sides of the –…
This is what I thought. So when one runs KDE3 applications from one’s distribution on one’s KDE4 desktop (as an example I have been using K3B, which according to its “About” dialog is still a KDE3 application) … I take it that Kubuntu have re-compiled the KDE3 source code of K3B against the KDE4/Qt4 libraries so that it would run? Or is it the case that the Kubuntu distribution (and others like it such as Mandriva) ships with both Qt4 and Qt3 libraries installed?
Both the Qt3 and Qt4 libraries are installed. You can’t compile a KDE3 app against the Qt4 libraries. (or vice-versa) While they are related, the APIs are not compatible.
No, you are just running KDE3 and KDE4 apps at the same time. They just use different toolkits (Qt3 and Qt4), just like you can run Qt4 and GTK apps.
OK, so installing and running KDE3, KDE4 and GTK applications on the one system takes up three libraries worth of disk space. Presumably if one runs one of each type of application, one has three sets of libraries loaded into RAM at the same time as well.
This makes a very good case for dropping one set from ones set of installed applications, IMHO.
Given that OpenOffice & Firefox are GTK applications, and given that KDE4 and Qt4 are the areas that are receiving almost all of the ongoing development attention … this in turn is starting to make a strong case IMHO for dropping all the KDE3 applications from one’s installation.
I hope that those KDE3 apps that have not yet been ported to KDE4 (K3B I’m looking at you) get a hurry on, then, or I’ll have to replace them with a GTK application instead. Maybe it is time to look at Brasero?
You are talking about 85 cents of hard disk space and maybe $2 of RAM.
The disk space is not as important, I’d agree, but RAM is quite often constrained on many systems still in use. Even some systems built in very recent times, such as some netbooks or handhelds such as Nokia Internet Table, are quite modest in terms of the available RAM.
I’d rather not have my systems heading in the same direction as Vista, if its all the same to you.
And you are not using k3b in a handheld or a netbook, so that’s a non sequitur.
BTW: I increased 4x the memory on my asus eee 701 4g for U$S 35 last week, to 2GB.
So, what specific device and app are you talking about here?
There are quite a few netbooks that essentially do not allow you to open the case. The are stuck at the hardware it came with.
So any combination of applications that builds your installed libraries un-necessarily. For example, EEEBUNTU and Easy-Peasy bothe come with Mono libraries, for the sake of running FSpot or Banshee or something. Ditch that, use Exaile or something instead.
GTK+ applications seem ubiquitous, so keep that set of libraries. You could stop there and run some very lite desktop such as LXDE.
That is probably going a little overboard, however. The netbooks can handle a little more than that.
If I add KDE 4.2, now with Qt4.5, to the mix, I get a very powerful desktop, and reasonably-well integrated GTK and KDE applications. I’d say that was a sweet spot.
So I don’t want, ideally, to add KDE3 libraries, and I don’t want to add Mono libraries, and I want only a minimal set of GNOME libraries (beyond what is required for GTK).
So … no K3B. That is a given for a netbook anyway.
No FSpot, Banshee, Tomboy Notes, GNOME Do or other Mono applications.
No KOffice 1.6. KOffice 2.0 would be OK, but it isn’t out yet. Shame, as this might have saved the need for OpenOffice.
GIMP, Inkscape and other similar applications should be OK.
VLC, SMPlayer, Quiteinsane and other Qt applications should be OK.
Amarok, Okular, Gwenview, Digikam, KMail, Kopete, Konqueror and other KDE4 applications should be OK.
If I pick and choose carefully, I will not be missing any functionality and yet I will keep to a minimum the number of libraries used.
Bonus.
Edited 2009-03-04 13:14 UTC
Reasonable, imho. I suspect K3B to be ported around the KDE 4.3 timeframe (coming summer) so within a few months you won’t be missing much.
No, they are not really. They more or less use their own self-contained application environments, and then utilize GTK for superficial linux “integration” (think filepickers etc.). This is actually worse, it’s like using two different sets of libraries for your application, and is why both applications are not very resource friendly regardless of the DE they are running in.
There’s no point dropping KDE3 apps for a user that finds the KDE3 apps useful and functional. They work just as well in KDE4, as KDE4 apps will work in KDE3. Yes, there is an additional memory footprint, but seriously, on even a semi-modern system, it’s virtually inconsequential. I suspect many distros will do what openSUSE will be doing, and just making the kde3 base packages (kdebase and kdelibs) available as dependencies for any legacy kde3 apps. It’s not that big a footprint.
With current amounts of HDD space & RAM such library overhead is practically negligible, ignore it IMHO.
In case I need it, here is independent backup for my statement “KDE 4.2 is already a good performer”.
http://www.itnewstoday.com/?p=198
I am also running Kubuntu Jaunty right now on my EEEPC netbook, and it is quite acceptably fast even on the netbook, even when running at low performance mode on batteries it is still useable. (I haven’t noticed any problem with wireless connectivity either … hmmmm).
Anyway, Kubuntu 9.04 of course uses KDE 4.2, and I believe that in turn uses Qt4.4, so the performance improvements offered by this release of Qt4.5 won’t be available in Kubuntu until KDE 4.3 in Karmic. But it is nevertheless nice to know it is coming. At a time when other desktop environments seem to be getting bogged down and slowing, it is always welcome news to hear about an upcoming performance improvement in the desktop that one is using.
What if we don’t want to use Mingw?
I would be very surprised if Qt4 compiled with MSVC++.
You meant “not surprised”, right? Of course Qt4 can be compiled with msvc++ — I’m doing it all the time. It’s just that there’s no binary download of the SDK compiled with msvc++, and that the cmake support in Qt Creator has hardcoded parameters for mingw.
It looks like Adept Updater for Kubuntu Jaunty (Alpha 5 version at this time) has just downloaded Qt 4.5 on my machine.
I’ll let you know how it goes when Adept finishes. If I don’t post for a while, you will know it didn’t go well I suppose …
Well I’m back!
Kubuntu Jaunty runs pretty quick on my main machine, (but because it is still alpha I do get a few application crashes) and to be honest I can’t say if Qt4.5 gave it a performance boost or not.
I still is very sprightly though, regardless, so at least it didn’t slow down.
good combination.