Kastle 2003: What to expect from Qt 4

On Saturday evening Matthias Ettrich, director of Qt development, gave within a talk at the KDE Developers' Conference 2003 in Nové Hrady -- besides a presentation of the company, the KDE/FreeQt Foundation and the past and present of the Qt development toolkit -- an outlook on Qt 4. Qt 4 is expected to be released in 2004 and promises to deliver increased performance, both at startup and runtime, more flexibility and productivity and changes to ease the learning process. Read more excerpts from the slides shown with the help of Matthias' home-brewn presentation program.

Qt 4 mostly tries to preserve source-compatibility with a little search and replace and a COMPAT compilation switch. More porting will be required for styles and code that uses the meta object system directly.

The increased startup performance will be reached through reduced number of symbols, less read/write data and fewer static initiliazers. Fewer mallocs, faster and more optimised tool classes and reduced memory consumption will improve the runtime performance enabling Qt 4 to run on embedded devices that are slower and have less memory than today's desktop computers too.

To back up these statements Matthias gave some numbers about Qt Designer which was ported to Qt 4 with only the necessary changes to make it compile: The libqt size decreased by 5%, Designer num relocs went down by 30%, mallocs use by 51%, and memory use by 15%. The measured Designer startup time went down by 18%.

Qt 4 will not be one library, but consists of many allowing finer granulation:

  • Qt Kernel lib comprising tool, io, thread classes and QObject/QKernelApplication
  • Qt GUI lib with QApplication, widgets, painter
  • Others libs for network, XML, SQL, openGL and other purposes

Included among the presented planned features of Qt 4 as of today are:

  • Designer split up into components. This makes it possible to create a form editor plugin for KDevelop.
  • Model/view classes for list box, tree view, icon view and table
  • New set of classes as part of a main window/docking architecture that distinguish between dockwindows and toolbars with support for tabbed docks.
  • Accessibility support for the Macintosh platform and for ATK.
  • Pixmap resource system
  • Several API cleanups like unifying different APIs and reducing number of concepts aim to simplify common usage, increase flexibility and remove embarassements.
  • New meta object code with static read-only data block (no constructors, no cleanup handlers, no relocations, no symbols) with significantly less generated code and minimal connect() memory overhead.
  • Better connect() syntax
  • New cast qt_cast(const QObject*) makes string-based QObject::inherits() obsolete.
  • A new class QPointer, which is successing QGuardedPtr, is lighter and faster.
  • The event filters were fixed and are now called from QApplication::notify() instead from QObject::event()
  • The threaded library will be the default with more thread-safety/reentrancy. Atomic refcounting makes QDeepCopy superfluous.
  • In the styles section the palette and background handling has been revised: A backgroundPolicy was introduced with non-toplevel widgets inheriting their background (policy) from the parent widget. Parents can propagate their content to child-widgets. This shall essentially give (semi)transparency for widgets. And last but not least system-wide double-buffering will allow flicker free update without any hacks at all.

Qt 4 will introduce a new consistent set of light, safe and easy to use value based container tool classes which are implicitly shared and highly optimised, both for speed and memory usage. Using them will expand to less code compared to Qt 3.x and STL which will stay available for further usage together with Qt.

QString and QByteArray were both optimised for performance and memory usage besides API improvements. An important change is that isNull() is dead and will be only available in compatibility mode. Functions like latin1() will always return a valid and never a null pointer. This change led to quite some discussion and aversions among the KDE developers but Matthias pointed out that there still will be isEmpty() and operator!().

Qt 4 shall be available within a year, with a short public Beta period next year before the final release. Among the open questions Matthias addressed to the KDE developers were if KDE will switch to Qt 4 and if so when, when KDE switches who does the initial port and where, and will KDE use the opportunity to refactor some of its architecture too? In return many KDE developers will, during the hackfast week, ask Trolltech developers for additions of classes and functionality which they find long-term missing and required by KDE.

Dot Categories: 

Comments

by Rob Kaper (not verified)

Damn computer sharing at N7Y. That was me, not Datschge.

by CE (not verified)

Yes, I doubt Datschge would write such things.

by Andras Mantia (not verified)

I was also surprised...

Andras

by whatever (not verified)

What makes you go offensive like that?

Anyway, my answer; no, because America has already shown more than once what software patents can do.

And we Europeans do NOT want that cruft in Europe, just to let big companies get even bigger by killing out small companies and inviduals.

(software) patents are useless and not used anymore for what they were invented.

by Mario (not verified)

his sounds like a stupid law that willl limit innovation.

by Morty (not verified)

Latest example of damage from the braindamaged patenting system in the US,
why we do not want this shit in Europe and why this is important for KDE.
Konqueror probably infringe on this too.

http://www.w3.org/2003/08/patent

by James Richard Tyrer (not verified)

Qt currently needs two features:

1. A font system which works.

2. A PostScript driver which works.

--
JRT

by me (not verified)

And a WYSIWYG-enabled painter

by John the anonymous (not verified)

I think that in this new major version Trolltech should refactor more things.

* Better STL integration (why not simply drop Qstring!) and follow modern c++ concepts (like namespace support -why should we keep decorating class names!- )
* Use C++ prepocessor capabilities. Why keep using a signal/slot system based on moc when you can do that with C++ templates in a more efficient way? Most of required things (serializing, type checking, ...) could be done in compile time (not with dinamic metaobjects like java) so it would be faster and smaller (yes, I know that not so frecuently used things like object inspection would require a dynamic version but it can be also done with c++ templates)
* Improve the GUI capabilities. The 3 generation desktops support avanced vector primitive rendering. For example, Mac OS X has a PDF-like rendering API very powerful to the developer; it can be HW accelerated and would help to reduce the client-server volume of data interchanged. The traditional fixed point QPainter/Qfont api is becoming very limited for new SW projects in KDE like Kword or KSVG (and new solutions are being proposed like Kpainter). And 3D graphics are the future! Maybe it's the moment to introduce some high level code (not only QGLWidget) -basic scene managers, ...- to test this market ;-)
* Better network and distributed processing orientation. Haven't Trolltech introduced a scripting system? They also have a xml language describing GUIs and a library supporting dynamic created interfaces -libqtui? used in qtdesigner-. Why don't encourage developers to create fast cross-platform distributed script applications? It will be similar to mozilla XUL technology, more powerful than DHTML (fast prototypes design, forget .NET!) I think MS is looking for something similar in Longhorn, and the most similar technology in KDE is Kommander (from the Quanta team). I think there is no need for big changes, everything is there (maybe a CSS Qt styles definition to make the whole thing more Web standars compliant)
* And other things I don't remember now (this is a enough long post :-) )

I think these are things that will have to be done someday. My reasons for doing it soon:
* Compatibility is not as critical as perfomance for many users. People who use Qt are looking for a modern C++ library and if these features are present I think version 4 will attract more developers.
* C++ compilers are getting closer to the standard

By the way. Qt really rocks! And more modularization and optimization are good news for the new version at least.

Just my opinion :-)

>>why not simply drop Qstring<<

No, please not the STL string which is completely inferior in practice. It just lacks dozens of features.

>>yes, I know that not so frecuently used things like object inspection would require a dynamic version<<

And exactly this is the killer feature needed for scripting/dynamic languages.

>>The 3 generation desktops support avanced vector primitive rendering.<<

That would be, indeed, nice, but maybe a little bit early. MacOS got Qwartz, Windows GDI+, but for X11 there is no finished implementation. Cairo graphics may solve that in the future though.

What in particular do you find QString has that an STL string does not?

Why would it not be better to add in the additional functions to string as described by Herb Sutter in www.gotw.ca/gotw

Can you give me an example of when a dynamic object inspection would be useful and unprogrammable using current C++ methods? I'm not saying there aren't any I'd just like to see the class of problems that require it.
Surely if it's not needed for most things then it should be done statically at compile time.

Regards

Nick

by Richard Moore (not verified)

Sure, take a look JSObjectProxy in KJSEmbed. There's also stuff like KSpy and plenty of other examples too I guess.

Rich.

1. Something like QString.arg() is extremely important, especially for i18n purposes
2. It lacks easy conversion from/to numbers
3. It lacks easy conversion to encodings (utf8 etc)
4. It lacks upper/lower case conversion
5. Instead of functions that people use in the real world it has stuff like find_last_not_of(). Huh?
6. It feels clumsy and not easy enough to use for a class that should be the most important class in any base library. Sure, I may find all the conversion stuff (numbers, encoding, case) somewhere else, but as it is the most frequently used class in most app it should make code short, sweet and readable, instead of designing a 'pure' class with a clean design but bad usability in the real world. It looks like a class designed by academics, not people who spent >50h per week writing applications

Imho QString is inferior to the std::basic_string template.
You can use the template with whatever charset you want. It doesn't make that much functions members, which shouldn't be (although there are some). Most of the stuff can be handled in non-member functions(e.g. your arg function). Not supporting upper-/lowercase conversion is because you just can't. How do you want to translate e.g. a "scharfes s" in german, should it be "SZ" or "SS" and this gets worse with supporting complete unicode.
...

Rischwa

But how often do you want that? You are talking about stuff that is almost never needed. I complain about stuff that's used all the time. When I implement a function, and I want it to be case-insensitive, I don't care which specific solution is taken for which platform. I just want it to work.
In some rare cases this kind of abstraction fails, but in the overwhelming majority of cases it just helps me to save my most precious resource, time. The STL design, like Java, usually aims to be correct in each and every case, while forgetting that a simple solution that works *almost* always is at least as important as a complicated, perfect solution. This is the beauty of Qt: it is designed from a practical programmer's point of view.

> Not supporting upper-/lowercase conversion is because you just can't.

Yes you can, the unicode specs specify what character offsets in a given unicode table should be mapped to an opposite case "partner". Not all characters can, of course, but this is a fairly reliable method of changing case, and is what QString uses.

No you can't, in many languages form of a glyph depends on context as well.
Anyway, I would give my vote for removing QString and creating QStringTools dealing with string/wstring/text files/unicode/conversions/locales/i18n, instead.
like this:

wstring QStringTools::stringToWide(int code_page_id, char* source);

by Nicolas Goutte (not verified)

There is a note in Qt's doc about why signals/slots are not made with templates: http://doc.trolltech.com/3.1/templates.html

Have a nice day!

Just wondering are all those packages in kdenonbeta, kdeextragear-1/2 and kdekiosk on the CVS going to survive during the KDE-3.2 -> KDE-4.0 transfer or are those cleaned up, and if so is there a page to show what programs do get included to the next version of KDE and what will stay or get eliminated?

And yes, the idea of rendering all GUI elements with OpenGL gets my vote as long as xlib, gtk+, SDL, tcl/tk, and other desktop libraries are supported via compability layers... ;-)

If they're useful to someone and their is no better competitor they will survive. Just like most apps did for KDE2->KDE3.

Ok, but could there be indication on some info-page of what would move up to the real distribution so people playing around building distros could wipe out unneccesary overlapping software?

The thing is you'll usually see the result after the progress is finished, not beforehand. =P
Kdeextragear-1/2 is by definition only loosely connected to KDE anway (they won't be included in official KDE packages but are released on their own) so it's up to the authors what they'll do with their work there. In general you can expect long time idling and broken packages to be moved to kdeblackhole, but that doesn't occure often either.

Why are you so eager to see some "wiping out"? The only "unneccesary overlapping" projects I see are in kdeextragear, but again: that is one of its purposes (see http://extragear.kde.org/home/about.php ).

Ok, my bad... :-)

Just it seems a bit ridiccilous that there are so many multiple packages for a single function on virtually any Linux distribution (and yes, I'm part of one packager team).

I just hoped that no later than that Qt4/KDE4 there would be some sort on spring cleaning happening as some of the stuff is there just to get bugzilla happy...

But the only place to see what packages are really in the development cycle can be only seen on the CVS/changelogs/kde-cvs-digest/kde-traffic and there could not be some sort of page indicating what parts should be (by administrators plans) going up (from kdenonbeta->relese and kdeextragear(s)->kdenonbeta)?

by Stuart Herring (not verified)

kdenonbeta and kdeextragear are not part of the KDE release cycle.

kdenonbeta is experimental stuff that probably doesn't even work with the current release, let alone a future one, and kdeextragear is for applications that want to be available for packaging from the kde cvs, but are not actually part of a kde version.

by Gerold J. Wuche... (not verified)

Scrolling a fixed amount of lines is not appripriate
in most cases. You either have to set it to a high
value to get good results with large windows, but then
you scroll more than a whole page in small windows.
Otherwise you need to use a low value to get good results
with small windows, but then your hand aches when you have
to scroll in large windows.

Scrolling a whole page isn't good either, because with large
windows you need to move your eyes from the bottom of the
screen to the top (this is straining).
An other reason why it isn't good is that you won't notice
when you accidentially scrolled two pages instead of one,
because the text you read is not shown any more.

My suggestion is to add configuration option that scrolling
defaults to scroll half a page. I created a patch and sent it
to kde-devel some time ago (for anyone who is interested).
The patch is quite simple. If you set the number of lines to
scroll to 0 (zero) than all qt GUI elements will scroll half
a page.

IMHO something in this regard should be done in QT4.
Does somebody from Trolltech please respond to my suggestions?
That would be great. :-)

by Alex (not verified)

KDE already has a mouse configuration dialog for all that in the Peripherals section of the Control Center.

What I would rather see is a smoothscroll like in Firebirds after you get an extension.

by Joe Hurke (not verified)

> Scrolling a fixed amount of lines is not appripriate in most cases.

I agree.
But I would like more flexibility in a different direction:
Mouse wheel support seems to be hard coded with support of 4th and 5th mouse button.
There a different wishes how to use these buttons:
http://bugs.kde.org/show_bug.cgi?id=48062
So many configuration options are needed to support these different wishes.

Certainly something like this should be done in QT4. ;)
Is anybody from Trolltech reading this? =o

by Right... (not verified)

http://www.suse.de/~bastian/Export/linking.txt

Also, i hope Qt will be easier to sue and use more standard C++ like templates and stop relying so much on the preprocessor.

by Bruno (not verified)

Templates makes your binary larger then it needs to be and thus decreases performance.

by Ian Bruntlett (not verified)

The key distro for KDE based developments in Europe (I'm in the U.K.) is, as far as I know, SuSE Linux.

So, for those of us who aren't fully aware of CVS and aren't happy with installing KDE and KDevelop by hand, when will these developments see the light of days in the latest SuSE Linux?

Also, I'd like to see some articles written about programming in Qt 4. I'm no stranger to writing technical articles myself (see http://www.accu.org/resources/public/terse/overload/UserDefinedTypesQual...
as an example, albeit the best ideas were given by the Overload editorial readers).

So I'd volunteer to write some articles about Qt 4 development, given appropriate hand holding (I've got a couple of years commercial C++ development under my belt and 6 years commercial C development).

Ian Bruntlett
ACCU Overload Editorial Reader

> So, for those of us who aren't fully aware of CVS and aren't happy with installing KDE and KDevelop by hand, when will these developments see the light of days in the latest SuSE Linux?

Probably in two weeks when KDE 3.2 alpha1 comes out.

by n/a (not verified)

Just hoping for more 3D-oriented system so there would not be necessary differences between OS and game modes (for future games on Linux).

I think, that for home users, one of the main disadvantages is lack of support for big desktop on two monitors (like FlatPanel + TVset) with two different resolutions. I have this problem with 17" FlatPanel (1280 x 1024) and TV (800 x 600).
The panel lays at the bottom of destop (1280+800 x 1024), so on the TV the panel and part of image is unreachable. The requesters are centered on the edge of screens (in the middle of desktop width). It is not possible to maximize window to only one screen. There should be one primary (for requesters and panel) and one secondary display (like ine windows XP and 2k).
I am not sure if it is right place to talk about it, because I don't know if the Qt or KDE is responsible for desktop behavior. But the problem is important.

Bednar

by Neal D. Becker (not verified)

I believe boost (boost.org) signals template library would be a good basis for replacing the qt signal/slot implementation.

by Henrik R Clausen (not verified)

I have one gripe with KDE 3.X or Qt 3.X that might finally get fixed:

When I grab a window edge with the mouse pointer _while_ moving the mouse, I'll often miss. It looks like the mouse position of the click itself is forgotten, and instead the current position is used. On slow computers or under heavy load that might be quite a few pixels wrong.

Why care about such a simple thing? Because it's a usability issue. The percieved reliability is affected by this, it feels wrong that you have to be careful about slowing down to grab something when you otherwise know what you're doing. The two largest (commercial) user interfaces both got this one right.

If I can post this to a Bugzilla somewhere, please point me in the right direction.