Trolltech has released the second and final beta version of Qt 4. You can download it from ftp.trolltech.com or from one of its mirrors. The online Qt Reference Documentation has been updated. Qt 4 is currently scheduled for final release in late Q2, 2005, with an intermediate Release Candidate planned for May.
In addition to improvements to the five key technologies presented in
beta 1 - Arthur, Scribe, Interview, Tulip and Mainwindow - the second
beta version incorporates nearly all new features, tools and resources
that will appear in the Qt 4 final release. Features now available
in Qt 4 beta 2 include:
- Improvements to the Qt 3 to 4 porting tool and supporting documentation
- Feature additions to Qt Designer, including support for MDI and
SDI modes, and support for custom widgets
- A new painting subsystem which allows device-independent rendering of pixel-exact images
- An improved input method framework
- Addition of XP (available under Windows only) and Motif styles
Additional improvements have also been made to the Qt3Support
Library. Trolltech aims to maintain the Qt3Support Library for the
lifetime of the Qt 4 series, and will also support the Qt 3 series for
a minimum of two years beyond the release of Qt 4.
Actually, arthur is a vector-based rendering engine.
The page that describe arthur only describe what changed since qt3, but in qt3 it was already possible to apply transformations (rotation, scaling, etc.) to subsequent drawing operations.
Since arthur, in addition to qt3, supports alpha and transformation of line width and brushes, as well as double-buffering, it has everything that should be needed to achieve those trendy animated eye-candy.
The immediate advantage of Arthur is a cleaner API and faster response.
Arthur supports several different types of backend. At the moment does not support Cairo (as I understand it, Cairo is still in a developer preview stage), however it does support OpenGL, which should allow for some powerful rendering.
As other comments have mentioned, Qt has supported vector drawing for quite some time.
Why is cairo "Vector graphics" and Arthur isn't? If you can draw a line (circle, spline etc.) between Point A and B, then you have vector based description.
Given today's technology, these vectors have to be converted into a pixel-based representation, no matter if it's Cairo or Arthur. At least as long as you don't use an ancient vector display.
To be honest, I don't know cairo at all. It doesn't use a scene graph, or does it? This would make it conceptually different from Arthur, but then I would be happy that Trolltech didn't follow that path.
Otherwise, what's the big difference? What - except for good taste - stops us from drawing our buttons with an animated and vectorized leopard fur look?
On Windows, there are a lot of good Qt 4.0 graphics demos in
Start -> Programs -> [Qt] -> Examples and Demos
See Vector Deformation, Affine Transformations, Path Stroking, etc.
Looks like vector graphics to me. And looks really nice.
(I don't know where these are on other platforms.)
To me, supporting "vector graphics" is an abstract concept.
Do you want to view SWF or EMF files? Do you want to view PDF files? Do you want to print to PS/PDF?
Here is my quick (uneducated) take on choices of various vector graphics formats in Qt:
SVG -> use ksvg libs
PDF -> use kpdf libs
PS -> use PDF engine?
EMF -> no idea; MS file formats are a pain
SWF -> no existing Qt app (?)
DXF (CAD) -> Open Cascade (Qt3-based)
If you need to do "heavy duty" vector graphics, maybe you can use something like Open Cascade, which an open source CAD toolkit. [http://www.opencascade.org/] Unfortunately, this is Qt 3, but it is a fantastic example of how powerful Qt can be for graphics. It will do BREP solids, meshes, irregular grids, etc. (basically anything a CAD system can do). Then you can dump to a lot of different file formats. I imagine PDF, SVG, etc. would not be incredibly difficult to support if it isn't there already.
There is also the Qt bindings for Coin3d for heavy-duty 3d graphics display.
Maybe you can poke around for other 3rd party Qt graphics libraries. There are a lot of others out there and GL support is really good.
Qt is pretty amazing for graphics work if you know where to look. I don't know nuthin about the GTK stuff. :)
It's unbelievable how beta2 has changed from beta1. I'm not talking about improvements here and there, but new cool stuff. Look at the Arthur Paint System for instance:
> QImage has become a paint device.
Great! Kolourpaint, KPDF, will have nicer graphics and lots of speedups due to this.
> We extend our gradient support. It is now possible to specify multiple colors at various positions in a gradient and different spread methods. We have also added support for radial and conical gradients
> It is now possible specify a QBrush as the fill method for a pen. This makes it possible to for instance, have textured text quite easily.
Any other words to add?
Yes, thanks TT! :-)
> It's unbelievable how beta2 has changed from beta1. I'm not talking about
> improvements here and there, but new cool stuff. Look at the Arthur Paint
> System for instance:
> > QImage has become a paint device.
> Great! Kolourpaint, KPDF, will have nicer graphics and
> lots of speedups due to this.
This is great but has QImage -> QPixmap conversion been sped up?
You should always assume the QImage->QPixmap conversion is very slow, as it will be over a network. QImage is local, QPixmap is on the server.
What network are you talking about?
> You should always assume the QImage->QPixmap conversion is very slow, as it will
> be over a network. QImage is local, QPixmap is on the server.
I'm optimising for the more common local case. In Qt3, it was very slow - I'm wondering if it has improved.
Heh...actually a dude and I have started to code an economy program with the Qt 4 libs.
It's called tribok. And what I have seen Qt 4 is much more better.
Are you creating the program using the model/view abstracts and other new concept or porting qt3-style programming/ideas?
Looking forward to see your creation! have fun, guys :-)
For the moment, we are just porting the qt3 code to qt4...but we don't use these tools like qt3to4 to port. We will see what happends, at this base of code dev we have done there isn't really much to talk about yet.
Thanks for the encouraging reply :)
i have used Qt3 already for some programs and have now read a article about Qt4 on a german linux magazine.
I'm a little bit upset. Qt has developed there own containers and so on for good reasons. But now Qt also develop his own "language", as i have seen there will be a foreach statement to iterate through Qt containers.
I'm not sure if i should like this development. It seems like Qt becomes more and more not only a toolkit or framework but even design his own programming language based on C++.
if it means easier coding and less boring/weird stuff for the programmer, why not?
It's just another way to iterate over the elements of a container. There are different ways to do this already, so I don't see what harm it could do add another method if it is much more clear than the others. Of course we can do everything in a pure STL compatible way, which is often even most efficient. But sometimes readability matters more.
yes, it's "just another way" but the question is if it is the right way to extend the language C++ with "just another way"?
As long as we talk about the toolkit/framework i have nothing against it if Trolltech needs a special container, data-type or keyword (e.g. emit,..).
But i'm not sure if it is the right way to introduce own statements like foreach.
If i develop a lot of GUI things with Qt for about one year and than someone ask me for a console-program i will start with C++ and will try to use things like foreach because i'm used to use this things. But it want work because this statement is not a C++ statement.
I think basically we can think about it, if a statement like foreach is usefull in C++. But we should think about it in the C++ standard and not in our own way and ower own lib. Because i'm fear that this will "pull C++ to pieces" and C++ code will have more and more differences to C++/Qt code. I think this is a bad development because it weakens the C++ Standard in the long run.
What if you try to use Qt functions? How is that any different?
What if I program in Haskell, Ruby, or any other good language for a year, and then someone requires me to write a C++ program? I'll have to get back in the swing of things.
If the bigwigs on the C++ standards committee see a foreach statement, and decide it's good, and put it in the C++ standard, and compilers finally support it, then great, everyone can use it. But that would probably take years, if it happens at all.
In the mean time, people can use Qt, and allow themselves a nugget of elegance in the overall pain that is C++ programming. :)
Some people like to do:
#define unless(a) if(!(a))
Is that also a capital sin? Why does C++ have macros, and why is the template language Turing complete if you're not supposed to do things like this?
> What if I program in Haskell, Ruby, or any other good language for a year,
> and then someone requires me to write a C++ program?
so you consider Qt/C++ as a own language if you compare my scenario with the scenario were someone programs in "Haskell, Ruby, or any other good language and than go back to C++"?
Thank you for confirm my statement.
"What if I program in Haskell, Ruby, or any other good language for a year, and then someone requires me to write a C++ program? I'll have to get back in the swing of things."
In the case of ruby, you can write ruby Qt or KDE programs with QtRuby and the Korundum/KDevelop RAD environment. So you might not have to get back to C++ programming anyway.
Turing Complete vs. Language usability?
I'm sure that both C++ template language and ruby were designed by very clever people. The difference is that ruby was designed from the ground up to 'be usable', and indeed it is. C++ templates were not designed with usability in mind and are one of the hardest features of any programming language to understand properly.
#define foreach(c,i) for (i = c.start(); i != c.end; i++)
this is not a new language!
"own programming language based on C++."
Why not take D? D is like Java and C# but lacks a class library.
I'm not a big fan of gnome but these one look really cool.
The real question is: can we do this with today's XOrg?
We were on that front with Impresario, Zack's WM, but the project stopped after finding arch problems in that implementation. Luminocity will stop too.. they don't have realized the problem yet.
Btw having Zack, with his experience on the field, hired at Trolltech and working on that stuff really gives us a gear more than our competitors.
>Luminocity will stop too.. they don't have realized the problem yet.
Can you explain this? What problem?
Unfortunately Zack does have a tendency to abandon projects when the going gets tough viz. Qt Mozilla.
>> Luminocity will stop too.. they don't have realized the problem yet.
You don't seem to realize that Lumonicity is just a concept.
The real thing (when it's integrated in Metacity) will be different and use the XGL server (thus fixing a number of issues), afaik.
What I found most impressive about those was the "live" pager, with constant updates not only for the windows on the current desktop but for those on the other desktops as well. Very impressive.
The rest of the features I don't care about so much ;-)
My only interest is whether the bugs related to font will be fixed.
Will the PostScript driver be fixed to work as well as the PS driver in OpenOffice does? Specifically, (a) will it be able to make scalable Type42 fonts from TrueType fonts and (b) will is support PS font metrics and printer resolution hinted font metrics. Note that currently Qt supports only screen resolution hinted font metrics.
Will the PostScript driver be fixed so that it gets the PostScript font names correct? My patch fixes this, but it is really just a kludge.
Will the font system be fixed so that it can properly deal with Type1 font names (Family, Weight, & Width)? NOTE that this is a general bug that perhaps needs to be addressed elsewhere. TrueType and Type1 font names are not the same when they contain a Width (and possibly some issues with some Weights other than Regular and Bold).
Will the font system be fixed so that it can properly deal with font faces other than the 4 mode paradigm: Regular, Bold, Italic, Bold Italic?
IMO, these are serious bugs and I am at a loss to see how Qt got to version 3.0 without their being fixed. And, I think that part of this is a regression (I used to use Helvetica Narrow, but now it doesn't even show up in the KDE font selector).
I'm pretty sure that Trolltech would be more than delighted, if you would try out Qt4 Beta2 and test if those font bugs still exists.
I am going to try a build of KDE-3.4 BRANCH against Qt-4. But ... (TM).
Some of these issues are going to require changes in application code -- the font metrics issue is going to require application changes.
Currently some of the font faces work correctly and some don't. Testing this is confounded by the fact that we don't know how much of the problem is in KDE and how much is in Qt. I have been told that these are Qt problems, but I have no way of knowing for sure. Perhaps some assistance from the maintainer of the KDE code would help.
I have found that the problem with Oblique being listed (INCORRECTLY) as Italic is a KDE problem. This hack appears to have fixed it:
diff -Naur kdelibs.old/kdeui/kfontdialog.cpp kdelibs/kdeui/kfontdialog.cpp
--- kdelibs.old/kdeui/kfontdialog.cpp 2004-11-03 09:15:17.000000000 -0700
+++ kdelibs/kdeui/kfontdialog.cpp 2005-04-13 17:45:33.000000000 -0700
@@ -476,8 +476,6 @@
if(pos >=0) style = style.replace(pos,5,i18n("Regular"));
pos = style.find("Normal");
if(pos >=0) style = style.replace(pos,6,i18n("Regular"));
- pos = style.find("Oblique");
- if(pos >=0) style = style.replace(pos,7,i18n("Italic"));
News Flash: Italic and Oblique are not the same.
Also please note that some fonts have a face called: "Normal" so substituting for that is also questionable. And, where does: "Medium" get replaced?
IAC, I have over a thousand font so it will take a while. :-) But, because I do have that many fonts, I can help with testing if someone is interested in fixing the problems. Clearly, we do need to get these font name issues fixed. It is not a usability improvement to have fonts displayed with the WRONG face names.
> I have found that the problem with Oblique being listed (INCORRECTLY) as Italic is a KDE problem. This hack appears to have fixed it:
Yeah, those replacements look strange. Unfortunately the commit message for the change doesn't really give a detail reason for this. (https://svn.kde.org/viewcvs/trunk/kdelibs/kdeui/kfontdialog.cpp?rev=1284...)
Is it possible, then, that my missing Helvetica faces are a KDE problem rather than a Qt problem as I was told?
For example, I have Helvetica Narrow installed (Type1). This used to work in KDE 2., but now it doesn't show up in the KDE Font Selector dialog box.
I now beleive that part of the font problem is in KDE -- rather than Qt -- code so I filed a bug report:
It was immediatly marked with Priority: VLO, which I presume is one small step above WON'T FIX.
Any word on when we might be seeing Qtopia/Opie releases based on Qt4? I'd love to see an HP iPAQ h3600 PDA/phone running Qt4 based Opie on Linux .
Work is being done on porting Qtopia to Qt Embedded 4. Opie has not yet begun, but will soon enough. There is a lot of work to be done jumping from version 2 to 4!
I hope you will be successful. Qt2 was a main reason for me to no longer develop stuff for Opie.
my build progress failed, is there a possibility to get a binary package for Linux/Win?
What was the error?
In file included from ../../include/QtGui/private/qpaintengine_x11_p.h:1,
../../src/gui/painting/qpaintengine_x11_p.h: In member function `virtual
QPaintEngine::Type QX11PaintEngine::type() const':
../../src/gui/painting/qpaintengine_x11_p.h:107: error: `qt_x11Data' is not a
member of type `QPaintEngine'
make: *** [.obj/release-shared/qapplication_x11.o] Error 1
make: Leaving directory `/usr/src/app/qt-x11-opensource-4.0.0-b2/src/gui'
make: *** [release] Error 2
make: Leaving directory `/usr/src/app/qt-x11-opensource-4.0.0-b2/src/gui'
make: *** [sub-gui-make_first-ordered] Error 2
make: Leaving directory `/usr/src/app/qt-x11-opensource-4.0.0-b2/src'
make: *** [sub-src-make_first-ordered] Error 2
Qt 4 is looking totally amazing, but I have to say that I am getting more and more disappointed by Qt Designer. The drag'n drop signal/slot connector is totally worthless for any application with more than a dozen objects, the new SDI mode is a hack, and drag'n drop of objects is a cute feature but a total pain in the arse if you have a fairly sizeable project. Designer is a huge part of Qt and its is not yet even close to being ready for release. Isn't this the last beta before we start RC releases?
You will have to wait until Qt 4.1 for a mature Qt4 designer and the missing classes of Qt3 (QCanvas, ...) being ported.