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.
Comments
Why didn't Matthias use kpresenter?
Because he's cool enough to write his own presentation tool. :)
Cool or fool - it's all the same...
Those are probably the five most insightful words ever written on this site.
So "not" was not really insightful? Just wondering.
Because kpresenter sucks ... openoffice Impress could sound an insult ... M$ PowerPoint could start tht third world war ... Gnome stuffs =8-| oohhh nooo ... the best thing was done his own tool
KPresenter does not Suck, I use KOffice for all of my everyday things and I do enjoy it. I look forward to the next version of KOffice and KDE
We just need someone to pick up the ball with KOffice--As a programmer, I am far more happy with KOffice but as a user, I am happier with OpenOffice. I often wonder if we could swap out various components of OpenOffice with KParts--at least simple ones like the File Open Dialog which would make it immensley more useful. I like its web page designer for making quite sites, openning and saving through so many different means would make updating content of websites a lot easier.
KOffice is a great theory and initial implementation but we need people to work on it. I wish so much that I had the time.
Matthew
> I like its web page designer for making quite sites, openning and saving through so many different means would make updating content of websites a lot easier.
Oh please! I don't know what "quite sites" are exactly but if I had been satisfied with it as a tool Quanta Plus would have died pre 2.0. Now 3.2 will have visual page layout... and imagine this, with a tool actually designed to work on web sites you can hit F8 and click a button to upload all the files you updated. Last I looked there was visual candy, but no real tools. We spent several years in development to make sure visual design can conform to the DTD you selected instead of hacking how it saw fit. I hope you're not suggesting OO as a viable alternative development path. Quanta 3.2 will easily put such rambling to bed.
> KOffice is a great theory and initial implementation but we need people to work on it. I wish so much that I had the time.
I had neither time nor many of the skills when I got involved with Quanta. I've had people tell me they wished they had the time who had a lot more free time than me. Rather than compare just look at the basic rule... you always find the time to do the things that are the most important to you. It's a matter of internal priorities, not external circumstances, that make you available. There are currently people working on Koffice but it could use more. I want to but I don't want to compromise Quanta/Kommander.
Eric:
Sorry to break it to ya: Quanta Plus' interface is noisy.
-Peace out
Have you compared it to dreamweaver MX recently? Much less noisy than that (but granted, less functional too)
I had annoying wrist problems when writing the presentation, and kpresenter still forces me to do many more things with my hands than just writing the text.
The little thinggy I was using instead was a 1000 lines hack I once did for fun. We now use it sometimes at Trolltech for internal presentations within the development team. It's unflexible, can't do effects and is rather boring. The "master slide" with the TT logo is hardcoded. But it allows me to write simple slides very fast and reorder them with little interaction.
I would have loved to "sex up" my presentation with some of kpresenter's many features, but I wasn't able to this time.
So, if you don't mind, any plans in releasing this thingy?
Your 1000 lines hack looks clean, lean and straight forward. Just enough to get a few text line to the auditorium, without messing up with mgp oder a huge application.
--
thorsten
>> # New set of classes as part of a main window/docking architecture that distinguish between dockwindows and toolbars with support for tabbed docks.
Yeah, better docking support, finally! :)
Will it also have support for creating a 'unified' main window?
eg. When you look at Windows (and I believe OS X) programs you'll see that everything is drawn correctly with no useless or missing bevels, with every Linux program (Qt, Gtk, whatever other toolkit) this has never been the case and it's one of the reasons why many apps still have that geeky look or looking like something's missing (like with KWrite; missing bevel around the text window - another example would be Konqueror; the toolbars and lower views don't flow into each other, it looks like they're patched together).
And about those icon views, will the native Qt views have support for alpha blended icons in Qt4?
(so not the current stippled icons, which look terrible (especially on TFT/LCD monitors))
And lastly, I really hope those double buffered widgets aren't going to make Qt4 slower.. (like happened with Gtk2)
> And lastly, I really hope those double buffered widgets aren't going to make Qt4 slower.. (like happened with Gtk2)
The problem is that with Qt 2 and beyond, half of the widgets are double buffered and half of them are not. I still see a lot of flicker in things like menus, but little in terms of things like text edits.
I think consistancy is good approach here. Also, remember that flicker is also an accessability issue, since a lot of people (est. 12.5% of the population) get headaches from seeing flicker on CRT screens. Using a LCD will help, but not everyone can afford one yet.
>> The problem is that with Qt 2 and beyond, half of the widgets are double buffered and half of them are not. I still see a lot of flicker in things like menus, but little in terms of things like text edits.
Yeah, I've noticed it when resizing windows with scrollbars in it.. usually gives some very bad looking white flashes (most themes don't set the background color to a sane value I guess?)
>> I think consistancy is good approach here. Also, remember that flicker is also an accessability issue, since a lot of people (est. 12.5% of the population) get headaches from seeing flicker on CRT screens. Using a LCD will help, but not everyone can afford one yet.
I'm still getting headaches when seeing flicker on my LCD..
That's an entirely different kind of flicker from the refresh rate/interlace problems which CRTs have. The 'update flicker' of GUIs is just... annoying :)
...the component API (Qt's answer to KParts etc.). Has it been shelved till Qt5?
Also according to DE-CVS-Digest for August 22 KDE dialog boxes can now be used outside of KDE apps. Will Qt take advantage of this to blend in a little more? Actually is Qt doing anything on its dialogs, I'm thinking specifically about the Open/Save dialogs. Everyone else has moved (or in the case of GTK is moving) on. They're looking pretty old fashioned now, any work on souping them up.
This is just icing on the cake though, Qt makes programming in C++ a dream, thanks to everyone at Trolltech.
Very good question. My guess is that it is just too complicated, and Qt is already quite componentized.
Regards,
Eron
While it is great that Trolltech concentrates on improving the core library, I didn't see much that interested me as a commercial developer. Maybe I missed something. As a developer, I am much more interested in productivity features ie improvements in designer, new widgets, alpha support in graphics, a better html help system, more support in cross-compiling, UML, integration with editors or IDE's, etc. RAD and the faster, better, cheaper mantra is not a goal in business today, it's survival and I just don't see anything here that really addresses this issue. Maybe Trolltech believes RAD belongs in the KDevelop and Umbrello projects - and while the work on those projects are impressive, the delivery, support, integration, etc is just lacking for regular commercial use. ie. Gideon has been out in various betas but I still can't get a binary copy for RH9 and don't have time to mess with CVS etc. We need a suite, not necessarily from 1 vendor or project, but that is compatible and works easily together. Bottom line: Library optimizations are good, but for a 50% speed improvement it's easier to buy next month's Intel box - coding productivity is our real bottleneck.
John
If coding productivity is your problem then why are you using C++? Since you have established that speed of execution is not a major issue use a higher level language to code in which will give you far better gains then the library can ever hope to give you. Then code only the parts the profiler shows you is too slow in a lower level language. Ovverall you app should be developed probably 9-10x faster and perform with 5-10% the speed of your current app but would bbe far cheaper to produce. You can often even get it faster since the higher level code is easier to use more intelligent algorithms for.
Maybe because C++ can be one the best languages regarding productivity.
STL and generic algorithms is the key.
Ever heard of Eiffel ?
AHAHAHHA HAHHAHA HHHAAAAAAAAAA AAAAAAAA AAAAAAAAAA AAAAAAAAAA
We did Eiffel in my first year of Uni, and everybody utterly HATED it..
They wanted to Java instead...
I have to agree, Eiffel does suck.
!!theObject.make();
Java bites and Eiffel's syntax is horrible. Just like Smalltalk: ugly as sin.
mtm,
My thoughts too. And add templates to the list.
John
I have not seen any way that someone can be as productive in C++ as they can be in python. There are other higher level languages also that can also be more productive.
Speed improvements are important for embedded systems, where it might not be
possible to just get more powerful hardware. As far as I know qt is
the best for seamlessly going from desktop to embedded without having to
do a whole lot of work.
You forgot a compiler! ;-) Course if you buy a compiler on Windows/Mac you'd get a full IDE with it. And of course on Unix there IS a stable verison of KDevelop. And there's QDesigner for application design, which when merged with the IDE of your choice gives you a powerful RAD system.
At the end of the day coming up with an IDE that hooks up with all the compilers and source control systems on all Qt's platforms is a complex project, and one that a lot of organisations won't need. E.g. they might have Visual C++ as a compiler, in which case they've got the IDE and SourceSafe for version control. Same with Unix: they've G++, KDevelop and CVS. An experienced professional developer should be able to set these up.
Don't see how new widgets and alpha-blending will help with "productivity". The widgets seem okay to an on-and-off again hobbiest like me, alpha-blending is handled by styles, don't see any great reason to have it in apps (there's always OpenGL). It's the utility classes that speed up implementaiton, a Qt equivalent to the KDE's KConfig and Java's Properties would be nice, implemented in a cross platform manner using, e.g. files on Unix and the registry on Windows. Some crypto classes would be nice too (nothing too exotic, SHA, MD5, DES, Blowfish if possible). These could possibly be worked into support for TLS networking. While I've never used it people do seem to want some sort of component technology as well.
I will concede that by and large this seems to be a behind-the-scenes release. The work on threading is great and must have taken time. Same with the optimisations. The fact is Qt is maturing, there aren't a lot of big huge leaps forward left for it to make!
> It's the utility classes that speed up implementaiton, a Qt equivalent to the KDE's KConfig and Java's Properties would be nice, implemented in a cross platform manner using, e.g. files on Unix and the registry on Windows.
You can use QSettings class, it works without any problems (Windows: registry or UNIX: ~/.qt/.${appname}rc).
As Matthias pointed out, the memory and speed improvements help mostly in case of embended devices, but I don't think that anyone will complain if Qt uses less memory and is faster. And they also focus on other things, including RAD. He said that with the new Qt Designer, it will be possible to embend it in KDevelop. BTW, KDevelop3 had only alphas and no betas, so don't be surprised if no distro ships it.
Andras
The talk was targeted towards open source developers, essentially things we considered the most interesting for the core kde developers here in Nove Hrady.
RAD improvements are definitely a topic for Trolltech.
Hi Matthias,
Thks for info - I can understand you were targeting the audience - I just wanted to put in a plug for what we need most and glad Trolltech will be addressing that.
btw Qt has been a great product for us and already greatly increased productivity and performance over Java swing (which even faster processors don't help much unless maybe using native compilation such as swt/gnu-j - but I find Qt is still easier to use).
I guess I vision the day of quickly creating some classes in Umbrello that automagically generate all the grunt code like gets,sets, deep copy constuctors,etc (maybe based on our own custom templates), then quickly laying out some dialogs in designer that automagically does all the io and validation tasks, then us coding our own slots and algorithms, then instantly running it thru tests in Kdevelop such as valgrind, then clicking to compile to any platform and then creating a nice installation package thru a wizard. Then it's simple to keep modifying program design and features. It seems many of the pieces are already there or coming, and wow - that would make for super extreme programming or maybe Moore's law of application development!
John Taber
I can fully see a kdevelop3-final, qt 4.0, and kde 4.0 all within the same timeframe (next year)
KDevelop 3 Final will be released together with KDE 3.2 based on Qt 3.2.
Gideon / KDevelop-3 should build (and, for the most part, work - some plugins may depend on KDE-3.2) on KDE-3.0.4+ and Qt-3.1+ (IIRC)
Well, as kdevelop3 will go beta as kde 3.2 goes beta? is that the plan?
cool :)
At last ! I'm very very happy to this moronic niggle in the API finally
go away. I'm also pleased to hear that the library is being split up.
I hope the thread support is faster. Our app spends a significant amount
of time locking and unlocking, but it's not even threaded (qt-mt is often
the only installed version ...)
What's wrong with isNull()?
This is some very interesting news!
Finally, Qt non-GUI is being split from Qt GUI. This will make it easier to use Qt in non-GUI applications under KDE. :-)
Speed increase? Oh yeah! Woohoo.
Accessibility support? I'm a bit skeptical of that one... Who thinks they can do it?
> Accessibility support? I'm a bit skeptical of that one... Who thinks they can do it?
They already have good accessibility support under Windows, all they have to do is extend it to OSX (Macintosh Accessiblity Manager) and X11 (atk/atspi, whatever..)
I don't want to be a wet blanket, but is breaking source and especially binary compatibility so soon really such a good idea? Optimisation and cleanups are great, but it doesn't strike me as being really important enough to make up for all of the headaches that will come with it. Hell, we can sit on our collective asses and do nothing for a year and Intel/AMD will provide us with a greater than 18% speed up. Binary and packaging compatibility is already a disaster on Linux.
(I thought that a lot of startup problems on Linux had to do with the limp runtime linker. Has anything been fixed on that front?)
--
Simon
So soon? Qt4 is expected a year from now. Could be more.
And with these changes you can now develop non-GUI libs that link against Qt core. That gain alone is worth it for KDE... DCOP for example.
Also, if planned changes are announced now, when Qt4 will hit the shelves, most Qt3 software developed in the meanwhile will be VERY easy to port!
It seems to me that until this stuff is mature, the occasional refactoring is something we'll need to suck up.
I.e., if it needs to happen, better to do it now than later.
And once it does happen, if they're right about lowering the bar for new programmers, then OSS may be well served by the move.
It's not so much about mature vs not mature:
http://konsole.kde.org/NoveHrady2003/Day2/dscf0158.jpg
Like Matthias says, where is Motif now? Even Windows has moved on with .Net.
Thanks for the link.
Although I stated it badly, I meant what Matthias said on the matter. I wholly agree with his conjecture.
>>Intel/AMD will provide us with a greater than 18% speed up
Yes, but not everybody plans to change it's computer in the next year.
I agree that binary compatibility is a disaster on Linux. However, this is the price of always seeking for better and more easily understandable code. I think it's more a problem of the distro makers, unless you use any of the source based distributions.
If you want KDE to beat the others GUI you have to make it faster than them, among other things. Many people choose IceWM for this reason.
Unfortunately, unless Intel and/or AMD decide to distribute new CPUs and motherboards at no cost, some of us will still be using our 400MHz PIIs a year from now.
> 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?
What about the answers?