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.

Comments

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.

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.

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.

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.

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

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.

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.

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.

> 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...

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.

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....

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.

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,...)

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).