Trolltech Releases First Qt 4 Technology Preview

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 which KDE is based on, is scheduled for final release in late Q1, 2005. Read the online documentation or jump to the download page.

Five new technologies, codenamed Arthur, Scribe, Interview, Tulip, and Mainwindow are being incorporated into the next major version of Qt 4.0. The technologies are:

  • Arthur: The new painting framework
  • Scribe: The Unicode text renderer with a public API for performing low-level text layout
  • Interview: A model/view architecture for item views
  • Tulip: A new set of template container classes
  • Mainwindow: A modern action-based mainwindow/toolbar/menu and docking architecture

This is a preview of some of the Qt 4 libraries, not of the entire application development framework. Most notably, new versions of Qt Designer and Qt Linguist are not included. The Technology Preview is meant to be tested on a limited set of platforms only.

Qt 4 still is in a very active state of development. Not everything is ready for prime time, and there are significant omissions. Most importantly, this Technology Preview is not meant to be used in production code or even for application development. Not all backwards compatibility functionality is in place yet but you're able to write small programs.

Dot Categories: 

Comments

by Richard Garand (not verified)

I've been doing some work on the C# bindings for Qt and KDE so that I can port a program, and for that program I found that using the CLR's XML reading classes is much easier than using Qt's, because i can use a single exception handler to catch and report all file loading errors. Exceptions can be inconvenient sometimes, but this is a case where they make things much easier (in C# it's expected that you'll catch exceptions for anything that goes wrong, unlike C++, but it still shows how error handling with the Qt classes could be simplified).

For people who argue that an unhandled exception is the same to a user as a segfault, libraries like Qt could add a catchall statement in the main loop that would report the error and allow the user to continue; well written code will ensure that this is possible without leaving a mess behind. Common causes of segfaults, like null pointer accesses, could work the same way since they don't actually damage the program's state, but the process will just exit wherever it is instead of going up the stack and cleaning up everything.

by Ruediger Knoerig (not verified)

you mean:

try{

}catch(...)
{

}
for all exceptions? And for file I/O errors there is a exception superclass...

by Marco Bubke (not verified)

The OpenGL Code looks really old fashion to me. Ok, VBO's are mostly don't needed, but the don't use automatic mipmap generation. glVertexi is mostly the slow path. Maybe they can change in QT5 the coordinates from integer to floats.

by Anonymous (not verified)

Why not in Qt 4 - if you provide them feedback?

by Marco Bubke (not verified)

Because its a big change. There is also hardware which have no FPU, for example many PDA's.

by anon (not verified)

> glVertexi is mostly the slow path

Unless people create 3d games with a lot of triangles with Qt4, it should be fine.

by aleXXX (not verified)

How about LGPLing libQtCore ?
This would make Qt the first choice for system programming (libs, daemons, etc.) for any UNIX/Mac developer.

Alex

by Corbin (not verified)

Then TrollTech's revenue stream would be killed off for everything except Windows programs. TrollTech has to get money from somewhere, they are a business after all.

For now its best for TrollTech to keep QT as it is.

by anon (not verified)

he was asking about qtcore, not Qt itself. I think that would have certain advantages, since I don't think people really buy Qt for lower level programming but rather for GUI programming. Qt4 could change that.

by Anonymous (not verified)

Matthias Ettrich declined this idea already last year.

by M (not verified)

Yes, it would be better if the community wrote a LGPL version of Qt for linux/*BSD, maybe starting with qt-core. I think that earlier or later this will happen. Btw, there is a free-beer version of Qt in Apples WebCore. But only for MacOS X.

by Anonymous (not verified)

> there is a free-beer version of Qt in Apples WebCore

KWQ? You don't know what you're talking about. It's not more than a compatiblity layer.

by M (not verified)

Of course its not a complete Qt implementation, but its quite big. Qt itself is also wrapping up several libs and interfaces on linux/X11 for example.

by aleXXX (not verified)

No, I don't think. Then this community would have to follow everything Qt does. Why should we try to take trolltech the business away ? It would be one of the most stupid things we could do.
But LGPLing libQtCore probably wouldn't take any business away from the trolls, but make QtCore an alternative even for closed source apps.
Nobody will buy QtCore if he just wants to write some small tool without GUI and stuff I guess. The business is mainly in the GUI and extensions I think

Alex

by M (not verified)

I agree that a lgpl qt-core would be nice. I have rewritten a few Qt classes myself using another C++ library as foundation, and it was not so hard. Maybe one day...

I am not so much annoyed by the fact that Qt is under the GPL and I have to pay to write closed source software, but rather by the fact that Qt is not developed more aggressively. I find it problematic that Qt already depends on glib for instance. This can lead to making the competitors product (Glib/Gtk/Gnome) the de-facto standard and themselves irrelevant.

by aleXXX (not verified)

Which part of Qt depends on glib ? At least the "ldd mainwindow" didn't show glib.

Alex

by Justin Karneges (not verified)

Did he say that publically? A URL would be nice. Of course, Matthias also reads this forum, so maybe he can just confirm here. :)

Along similar lines, another interesting possibility would be a free QtCore for Windows. After all, 90% of QtCore is already freely available on Windows anyway, using code straight from the Free edition. Even the tool programs, like qmake and moc, are free. I doubt anyone would pay for _just_ QtCore, so I say Trolltech should simply make the last bits free and reap the publicity.

Hook 'em on QString while they're young. ;-)

by Matthias Ettrich (not verified)

I did? I don't even remember having spoken about it, but ok, I might just as well.

The dual-licensing model is based on a simple principle: quid pro quo. Either you give back in terms of code (by being part of an open source community that shares code and knowledge) or you give back in terms of money (by buying a license). The model cannot work with the LGPL, thus we will not do it.

I understand the request was about libQtCore only, but to me there is no difference in principle between libQtCore and other Qt libraries. They both require work to write and maintain, and they both reduce work when being used.

It's a bit like Robin Hood. He could only give to the poor because he took it from the rich. He would probably have gotten great publicity had he given to both the rich and the poor, but I doubt his business would have made it through the dotcom bubble with constant growth, or even be profitable today.

by Eric Laffoon (not verified)

> It's a bit like Robin Hood. He could only give to the poor because he took it from the rich. He would probably have gotten great publicity had he given to both the rich and the poor, but I doubt his business would have made it through the dotcom bubble with constant growth, or even be profitable today.

LMAO!

One can only speculate whether Robin Hood's business model changed or Nottingham's social programs reduced demand. It's possible too that Scottland Yard and Interpol discouraged this romantic tradition, or nobles only carry plastic nowadays. In any event now that Robin Hood is not publicly traded we cannot review his quarterlies and know for sure.

Of course today many of us who follow this noble tradition today are forced to ask the rich to participate, and unfortunately almost nobody thinks they are rich. I wept because I had no 64 bit processor to compile what I downloaded on my DSL... and then I saw the man with a 200 MHz Pentium on a dialup. There but by the grace of a few thousand bogomips go I...

by aleXXX (not verified)

Ok.
Now that libqt is split, will also the commercial license be split (i.e. will it be possible to buy only a QtCore license) ?

Alex

P.S. I still think getting commercial developers hooked with a LGPL QtCore so that they can't live without a commercial QtGui anymore wouldn't hurt Trolltech's business

by perraw (not verified)

I have just done "make install" and are ready to take a look at it. One thing I noticed during configure was that it required XCursor 1.0, and I had 1.1. I changed the test scripts so it would allow 1.1 as well.

The Qt Paint engine test (Arthur) for alpha blended primitives was butt slow on my machine. But I think I read somewhere that at this stage it was unaccelerated on X11. The open gl thing was fast though.

The textedit demo felt faster. A bit surprise that it doesn't select the whole word if you start at the middle (yes, like windows does) and move left/right.

Plasmatable, butt slow here. Probably 1/3 rd of the speed my i386-sx 16 did in a plasma demo :=)

Toolbar demo, sad to see that you can't have the toolbar next to the menubar like in IE on windows :( It can save you screen space.

Then I would like to see async sql queries. But I'm not sure yet if they are. Would be so cool to have a signal fire when the query is done. Sometimes sql queries take minutes before result is back....

Will give it a greater than-5-minute-spin tomorrow :)

by Matthias Ettrich (not verified)

The plasmatable is not a plasma demo, it is a QTableView demo. It abuse the model/view paradigm to show its flexibility. The plasm table is a basically a spreadsheet with every pixel being one cell. Try selecting the cells with the mouse, and you'll see.

While it is slow for a plasma demo, it is fast for a table view.

by aleXXX (not verified)

Yes, same here for the alpha blending.
Otherwise, cool :-)

Alex

by Asdex (not verified)

> The textedit demo felt faster. A bit surprise that it doesn't select the whole
> word if you start at the middle (yes, like windows does) and move left/right.

Nice, I have always hated that windows-"feature".

by Richard Moore (not verified)

I've written my initial thoughts on Qt 4 after playing with the new code on my blog at http://www.kdedevelopers.org/node/view/506 if anyone is interested.

Rich.

by aleXXX (not verified)

Two things from my side:
-hopefully the removal of setAutoDelete(true); doesn't break too many applications (i.e. introduces mem leaks), I used this feature all the time.
-docs have to be updated so that it's easy to see which classes are in which sub-library (QtCore, QtGui,...)

Alex

by aleXXX (not verified)

Simple test:
int main( int argc, char ** argv )
{
QString s="hallo welt";
cout<

by Nicolas Goutte (not verified)

Do you mean that setAutoDelete does not exist at all anymore or just that it defaults to not delete now (setAutoDelete(false)).

If it is just the default mode that was changed, perhaps the developers should be made aware of it, so that they can change current code to remain compatible.

Have a nice day!

by Anonymous (not verified)
by Nicolas Goutte (not verified)

H'm, annoying indeed.

Have a nice day!

by Matthias Ettrich (not verified)

QPtrList and friends have not changed at all, they just moved into the compat library with all their glory (including setAutoDelete())

by aleXXX (not verified)

Any comments to libQtCore licensing ? Are you considering LGPL ? Or will it definitely stay GPL ?

Bye
Alex

by James Richard Tyrer (not verified)

I read that "Laying out text using design metrics (WYSIWYG) is currently disabled".

So, does anybody know for sure if they are going to fix the font metrics issues. Also, do they know that you need to be able to select if you want something formated for screen rendering or printer rendering? Currently we have ONLY screen rendering.

It says nothing about the PostScript driver. I hope that this will be fixed. As I presume that most people know it does not get the PostScript Font names correct unless you embed the fonts. The correct way to do this is to use FontConfig & FreeType2 to get this information from the font file.

I also found that there is an inconsistency between the way that TrueType and Type1 font families are named and the current version is still confused by this. It appears that Qt is designed to work with the TrueType method. In which case, it will need to convert the Type1 family names into TrueType family names. Personally, I would like to see it the other way, but this would require rewriting some of KDE as well -- the KDE Font Selector would need more windows (2 more I think but the second one wouldn't be used much and the windows would have to interact because not every combination would be available).

And, a general solution needs to be found for the fact that not all fonts have:

| Regular | Roman, Bold, Italic, & Bold Italic

And worse, some fonts have more than one weight of bold. The kludge in the current version only works for the fonts included in the PostScript driver code. If this (a table) is the solution, it needs to be in a configuration file, and we need a KDE GUI program to edit it (a KPart since the font installer would also need it and you should be able to access it from the font selector).

--
JRT