Trolltech has announced the availability of the first Qt 4 Technical Preview. Qt 4, the next major release of the popular cross-platform C++ application framework.
Trolltech Releases First Qt 4 Technology Preview
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Qt 4 includes a number of features designed to greatly ease multithreaded programming, such as invoking slots for signals in a different thread. With the new painting engine it will certainly put GTK to shame. I for one will be testing this out extensively, in hopes of perhaps purchasing it in the future.
> With the new painting engine it will certainly put GTK to shame.
Is this the GUI rendering system? What will put GTK to “shame”? Performance? Just features and abilities that it will have the GTK doesn’t (and could you include what those are)?
I don’t know that much about the internals of QT, some I curious to know how this will effect KDE.
Thanks in advance…
The painting engine is what Qt uses to draw it’s graphics. See:
http://doc.trolltech.com/4.0/arthur-overview.html
Among other things, the new paint engine has an OpenGL backend on all platforms, and is fully double-buffered. That is essentially what Microsoft is promising for Avalon’s GDI layer in Longhorn, only this uses OpenGL rather than Direct3D. I don’t know about “puttig GTK+ to shame,” though, because GTK+ will be moving to Cairo soon. Though, I have to say, I prefer Trolltech’s way of providing a cohesive paint API on all platforms as opposed to what the GTK+ folks have proposed, which is to make Cairo directly visible to the programmer.
On an unrelated note, I’m very interested in seeing the new Qt4 style API. The Trolltech folks have made noise about enabling applications to go beyond the current look, towards a more web-inspired look.
It’s called Arthur.
Description here:
http://doc.trolltech.com/4.0/arthur-overview.html
Very impressive.
But I think the expression “put GTK to shame” is inappropriate. GTK is also a great piece of software.
So let’s not start the great GTK vs. QT debate, eh?
Sorry i’m a big n00b i guess, but people said it would support opengl, so this means desktop will be using your gpu?
Arthur sure looked interesting, in the hands of a good developer it can probably bring out some nice magic.
Oh yeah, please keep out the Qt vs. Gtk flames for once.
The OpenGL backend has got me thinking. How far away is the possibility you guys think of getting OpenGL drivers running without X in Linux instead of the current GLX ones?
Because with that, Qt4 and a bit of activity on the already ongoing KDE without X effort could mean you’d have a potentially hardware accelerated desktop (and then things like GLSL implementations of font rendering, drop shadows and the like is but a level of indirection away).
This however could also become possible via the new X server work on FD.org if they can agree on actually working on the implementation which there was a rather interesting thread about it last month on the xorg list.
But I think the expression “put GTK to shame” is inappropriate. GTK is also a great piece of software.
Well, GTK and Gnome together have always had good unicode support, and I think this is as a result of that:
Scribe: The Unicode text renderer with a public API for performing low-level text layout
Open source software in action.
I don’t know about “puttig GTK+ to shame,” though, because GTK+ will be moving to Cairo soon.
Well, Cairo looks promising but it is terribly slow at the moment and won’t really be practical for most people to program with, or even use, for quite a while to come.
On an unrelated note, I’m very interested in seeing the new Qt4 style API. The Trolltech folks have made noise about enabling applications to go beyond the current look, towards a more web-inspired look.
So am I.
Sorry i’m a big n00b i guess, but people said it would support opengl, so this means desktop will be using your gpu?
Possibly yes. If you have a hardware accelerated OpenGL option, through your nVidia or ATI drivers, for example, yes – they will simply be used, and Qt will have no knowledge of them. If they are not hardware accelerated, then it will just be software emulated. However, I certainly don’t think KDE is going to extensively use these features any time soon.
The OpenGL backend has got me thinking. How far away is the possibility you guys think of getting OpenGL drivers running without X in Linux instead of the current GLX ones?
Absolutely none. Qt and KDE use X, period, and if you’re going to use OpenGL on Linux, that means hardware accelerated X drivers.
Because with that, Qt4 and a bit of activity on the already ongoing KDE without X effort could mean you’d have a potentially hardware accelerated desktop (and then things like GLSL implementations of font rendering, drop shadows and the like is but a level of indirection away).
Doing that is difficult, because it needs to run on the vast majority of machines out there – and still being used. A 3D desktop using a great deal of hardware acclerated features? Definitely not. A 2D desktop with some 3D features where they make sense? Possibly.
What about the other vectorized/alterative technologies :
like fresco/berlin
or directfb
How do they count in the ecuation ?
I know fresco in his MXXX releases is tring to provide a vectorized rendering but using a self toolkit wich resembles motif.
DirectFB is dealing with something that i dont understand , they ported GTK over but few people adopt it , and i saw posting about porting QT also , but this did not happen.
About QT/GTK “Battle” , The Gui Toolkit Framework page really says it : QT – Best
It is kind of best because of modern desing, easyness in development
It is bad cause of license issues
GTK – Is free and also hard to learn because of noncontinuous documentation(scatterd over the web), but studious people can find it and for this matters it is “best” in its own category.
So … use what you like most … QT is good , GTK does the job , they are verry close and because of this the only thing that matters is programmers own quallities and the way he uses the provided tools.
Just wanted to point out to the ones interested who mentioned it, that cairo does have an opengl backend called glitz (if I am not mistaken). The reason GTK is using cairo is because it has a nice API and is portable to other platforms (Windows, OSX, GPE, etc…) and the Gtk/Gnome community doesn’t like reinventing the whell.
Qt obvioussly can’t use it because they don’t want to depend thier whole cross platformness of Qt on the cross platformness of cairo (so if cairo takes half a year to be ported to OSX they don’t want to be stuck behind it).
The thing I am more exicted about is having Qt being split into the GUI part and an underlying library (like glib) which should help stop some flamewars on fd.o about glib.
which should help stop some flamewars on fd.o about glib.
Actually, it’ll most likely reignite the flamewars. Some GNOME people have been pushing fd.o as something more than a standards body. Some want it to become a common platform for *NIX GUIs, with shared implementations. Whether they will welcome qt-core, as they have glib, into these reference implementations remains to be seen. If there is opposition to using qt-core in places where the license doesn’t affect application developers (eg: a sound server), then there will be some credibility issues to face.
I’m under the impression that both QT and GTK+ draw their widgets on in-memory bitmaps independently of the underlying platform and then draw those bitmaps utilizing the underlying platform.
Both QT and GTK+ seem to allow for complex themeing using libraries.
Is it possible to make these libraries implement a simple theme that could be drawn using X Windows System primitives, instead of having to be painted onto a in-memory bitmap that has to be transferred to X for drawing?
You’re wrong. Both Qt and GTK+ draw their themes via engines. Theme engines use the underlying painter. So the extent to which themes draw using underlying primitives is limited by how much the painters do so. In practice, most primitives (lines, rectangles, fills, etc) are hardware accelerated. However, gradients, something which is (tragically) popular with many themes, are not accelerated, and are thus drawn in software. One of the key advanced of moving to the new Qt painter is that these gradient operations can be accelerated via OpenGL or RENDER.
The new painting engine that QT has can use a number of backends with Cairo being a possible one in the future (an Avalon backend is possible too). In addition, the complaints about glib usually (from my understanding) aren’t so much about it being a separate library from the toolkit so much as the programming model it requires. Many people consider cajoling regular C into an OO style to be ugly.
Currently nvidias opengl-libs doesn’t support prelinking. So anyone using nvidias drivers in combination with qt has to recompile qt without opengl-support if they want to be able to prelink software dependant on it (kde comes to mind). This is already an issue since the default option when compiling qt is to link against gl-libs. I guess there’s lots of people out there thinking they have a prelinked linux system, while they really don’t. This might become even more of an issue if compiling without gl-support becomes a big loss.
I think it’s time to complain to nvidia, since their drivers make many peoples applications load slower without giving a warning.
This is a bug in Qt which IIRC was resolved some time ago. Qt has to dlopen libGL, there is no way around it, libGL cannot be prelinked as it’s not PIC. End of story.
Oh, and the reason TrollTech aren’t using Cairo is almost certainly not related to portability (there’s nothing inherantly unportable about it) or scheduling (they could do the work themselves). It’s probably so they can enforce their licensing – Qt has to be entirely the work of TrollTech so they own the copyright for that to work. Incorporating Cairo that deeply into Qt would make Qt a derived work of Cairo in the eyes of the law, and so they would have to LGPL it (or it would not be compatible license wise, not such which).
I would really like to check out Qt on Windows, but it is not available.
Perhaps Trolltech is going to drop the Windows platform soon that is why.
Just wanted to point out to the ones interested who mentioned it, that cairo does have an opengl backend called glitz (if I am not mistaken). The reason GTK is using cairo is because it has a nice API and is portable to other platforms (Windows, OSX, GPE, etc…) and the Gtk/Gnome community doesn’t like reinventing the whell.
Glitz is used by OpenGL to render text. So its more Cairo + Glitz acclerated by OpenGL. With that being said, I’m not too confident about GTK considering the terrible slowness of GTK+. It seems as though there is something that is holding GTK back, I mean, I’ve never seen such slowness ever. Whats the story?
Oh, and the reason TrollTech aren’t using Cairo is almost certainly not related to portability (there’s nothing inherantly unportable about it) or scheduling (they could do the work themselves). It’s probably so they can enforce their licensing – Qt has to be entirely the work of TrollTech so they own the copyright for that to work. Incorporating Cairo that deeply into Qt would make Qt a derived work of Cairo in the eyes of the law, and so they would have to LGPL it (or it would not be compatible license wise, not such which).
What on earth are you smoking?
Cairo is a free software library released under the MIT license.
What has the GPL/LGPL have to do with the price of fish in north Mongolia when the sun is setting and the owl is hooting?
My bad, I’d forgotten Cairo was MIT licensed. Well, in that case I’m not sure why they went their own route – maybe they started development on Arthur before Cairo was mature?
“My bad, I’d forgotten Cairo was MIT licensed. Well, in that case I’m not sure why they went their own route – maybe they started development on Arthur before Cairo was mature?
”
yes and there nothing preventing arthur targetting cairo as one of the backends in the future. keep in mind that none of DE’s actually use cairo now. maybe its not mature enough?
>I would really like to check out Qt on Windows, but it is not >available.
>Perhaps Trolltech is going to drop the Windows platform soon >that is why.
Not in a million years, I believe the windows platform is their main market, that’s how they generate the revenue to continue development. Without it they wouldn’t exist. I wouldn’t be surprised that the Linux version is ‘free’ because Linux users tend not to purchase development tools, hence providing it for ‘free’ doesn’t loose them very much but does gives them visibility.
> Perhaps Trolltech is going to drop the Windows platform soon that is why.
Considering that Trolltech exists mostly because of their robust license sales on Windows, I really doubt it 🙂
> anyone using nvidias drivers in combination with qt has to recompile qt without opengl-support
Wrong: ./configure -dlopen-opengl
Trolltech probably felt Cairo was inadequate and wanted a more familiar technology built for Qt.
However, of course, Cairo could be used with Arthur later.