What to Expect From Qt 4

An anonymous reader writes "A presentation given by Matthias Ettrich (director of Qt development, author of LyX, and founder of the KDE project), was given to the annual KDE Developer's Conference in Nove Hardy, Czech Republic. In this presentation, Matthias details what's going to be new in Qt 4.0, which will be used as a base for the next version of KDE after 3.2. Apparently, Qt 4.0 will not only include faster startup times and lighter memory usage, but will have sweeping architectural changes, including a splitting of Qt's GUI classes and non-GUI classes."

Comments

Re:It Sounds Nice

[Coventry]

Remember, QT is a library, and trolltech makes their money from it. I'm pretty sure that all that will be needed for most apps using current QT is a recompile with the new tools (QT has a tool used as part of the Make process). To use the new features might require changes to code, but thats a different story - you're already changing your code to add new features.

Here's what I expect

[Rosco P. Coltrane]

Qt is great (well, if you like C++ and you don't mind the QPL), but there's really one thing I'd like: when will it ever have a font scheme that allows me to use AA fonts together with non-truetype X11 core fonts?

Re:Here's what I expect

[DanMilburn]

You're aware that the QPL is, more-or-less, an open source license right? People didn't like it because it didn't meet the Free Software Foundations definition of free (meaning that, according to a strict interpretation of the GPL, it was illegal to distribute KDE in binary form), so Trolltech started licensing it under the GPL, leaving the option of accepting the terms of the old license instead.

As for dual-licensing it commercially and as free software, well, I don't see how that forces anyone to do anything. If you make non-free software, you pay the fee for a commercial license, and it's been that way since Qt was created. The growing success of Qt might encourage people to do this, but they're certainly not forced to. And if that happens, hey, Trolltech are successfully creating and supporting free software, and managing to make money. I don't see that as something to be wary of.

Re:Here's what I expect

[Anonymous Coward]

You are confusing development with execution.

The QPL explicitely grants the use of Qt as a runtime for any "legally developed application" that needs it.

So, you could just get a QPLd Qt and use it as a runtime for the GPLd code.

Alternatively, you could get it under both licenses, since it is dually licensed. There is no reason to choose one license.

KDE ...

[biggj]

I have had trouble's with KDE... It tends to be bloated and slow. But but there are a lot of useful apps on it, so maybe this will fix some of it's issues.

RTFA!

[Anonymous Coward]

Paragraph 2:

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

How much stuff do you think uses the meta object system directly, aside from the internals of KDE?

Re:What I would like to see..

[Anonymous Coward]

Yes, some of the common ones include

Opera Web browser
LyX word processor
SuSE's YaST.
Scribus destkop publisher.
The Linux 2.6 QConf
Kylix.
YHBT Business books
and hundreds more.

Re:What I would like to see..

[AArmadillo]

There are many. One of the advantages of Qt is that it provides a common interface to X-Windows, MS Windows, and Mac OS GUI programming. Qt is entirely independent of KDE, the only reason an application would be bound to KDE is if it utilizes the KDE extensions to Qt.

Before you try to book a hotel room

[SlashCrunchPop]

I believe someone got the name of the town wrong, it's Nove Hrady and not Nove Hardy.

Re:Canopy Group

[Anonymous Coward]

Uh, Canopy Group isn't their parent company. The Canopy Group just owns 4% of TrollTech.

On the other hand, the Canopy Group owns 43% of SCO/Caldera (might have changed since dec. 2002 though)

Quit your Trolling.

Re:QT4

[SlayerDave]

That's true, the Java API has a very large number of classes. But what I like about their docs is the use of frames, which is normally quite annoying, but is well-done in the case of JavaDoc. Also, you can select a particular package to view, such as javax.swing or java.util, which greatly limits the number of classes you have to browse. Also, I like the ability to see clearly what members are new in each class and what members are inherited and/or reimplemented. Also, getters and setters are listed together in the Java docs, but not in the QT docs. I think these features make the Java docs easier to navigate than the QT docs.

Re:QT4

[chowells]

Well plenty of KDE developers use emacs/xemacs so presumably with the emacs scripts things in kdesdk so presumably it is possible to get emacs sorted :)

Hahahaa no we didnt

[HanzoSan]

Japan has a better powergrid than ours. Who gave you the idea that we had the best in the world? DO not assume our system is the best just because we are the USA. Japan has alot of things better than us, as does Korea. Japan has the best power grid in the world, the most efficient public transportation in the world, the best cellphone technology in the world. They also have better robotics than us,

South Korea is the most wired country in the world, with the best internet technology in the world.

just because its USA does not automatically equal best.

GTK - nyed!

[Moritz Moeller - Her]

Most of the applicatons you presented as GTK apps do not use GTK widgets:

Openoffice/Staroffice does not use GTK at all (in fact the first SO port to Linux was done by Matthias Kalle Dallheimer, a KDE founder...)

Mplayer has an optional GTK gui, which is hardly used by anyone. It also has at least two KDE guis. Not a very good GTK app.

XMMS has it's own GUI, GTK is basically used for the file dialog, which is arguably not the most impressive part of GTK.

Mozilla/Netscape uses XUL, it's own toolkit, again no GTK widgets are used, just some basic drawing routines.

This leaves GIMP (functional, but ugly) and GAIM (never used it, AOL is not my thing) for GTK.

Re:use of macros in C++

[js290]

Ever tried stepping through code with a debugger that's full of macros? Not fun, unless you like printf's. As far as Troll Tech using macros for their signal/slots, I don't care as someone using their toolkit. One less abstraction to worry about.

Not exactly necessary...

[Moritz Moeller - Her]

Just start e.g. kmoon or klipper. KDE and GNOME use the same docking protocol, so any existing docked program would suffice.

Re:Trolltech and Canopy/SCO

[Anonymous Coward]

Novell is not part of Canopy. The former founder of Novell started the Canopy group as a tech fund but Novell has nothing to do with Canopy these days. It is interesting to note that the Canopy groups home pages has a quote from Darl McBride and their latest news proclaims the termination of IBM's AIX license.

Re:How about more standard C++

[Anonymous Coward]

Well, to be honest, the QString class is substantially more powerful than the C++ string class. Most especially in casting to and from other data types. Moreover, it supports the full range of internationalised characters, it automatically casts as neede and passes by value as needed as well.

On the whole, it acts in a more intitive manner for the programmer, and that is true of almost all QT classes. That's the thing about QT, it works the way programmers want it to work. Say what you like about the licencing or the people or whatever, but it is a great toolkit to code with.

KDE Conference Talk Writeups

[JRiddell]

Writeups of the talks I went to are at:

the Nove Hrady wiki.

Re:Why turn KDE into Gnome?

[IamTheRealMike]

I guess you'll be pleased to hear that GNOME 2 remains fully backwards compatible throughout the 2.x cycle - in the history of the project, it's broken compatability in a major way only once, compared to KDEs 2 times (though 2->3 was extremely trivial for 99% of apps).

Mono is entirely irrelevant - it's not related to the GNOME project other than having Miguel/Ximian involved, and you are certainly not forced to use it to write GNOME apps.

Basically, I think you're misinformed - if you write an app for GTK2/GNOME2, it will continue to work for quite a long time, until the next major revision (which is going to be needed simply in order to properly sync KDE and GNOME around standards eventually anyway). So, I don't know what you're complaining about really.....

Qt on DirectFB

[dok666]

You might want to have a look at this new QtDirectFB screenshot:

http://www.directfb.org/screenshots/FirstQt.png

I'm really looking forward to having the KDE libraries independent from QtX11.

Best Regards,
Denis Oliver Kropp

Re:Trolltech and Canopy/SCO

[be-fan]

Dipshit.

A 5.7% stake hardly makes TT a "Canopy puppet."

Hint: Look at Canopy's website. Note that TT is listed under "Portfolio Companies." Understand that this in no way means that they are controlled by Canopy group. Hell, Microsoft owned about as much of Apple after their $150 million investment. Did that make Apple a Microsoft puppet?

Re:QT4

[Arandir]

First, the signal/slot mechanism really bugs me. I am annoyed with the need to use non-ANSI C++ techniques (e.g. public slots, moc) to achieve results that could easily be done with legal C++ code.

There is no ISO C++ mechanism that does the same thing that signals/slots do. None. None at all.

Now before you start talking about Boost::Signals, libsig++, gtkmm, etc., take a step back. Those things you're talking about are libraries, just the same as Qt. They are not standard mechanisms any more than gettext or libxml are standard mechanisms. Every bit of the code that is in Qt to implement signals/slots is standard ISO C++ code. No different than with Boost::Signals.

And as opposed to those other "standard" mechanisms, Qt signal/slots are extremely flexible.

The QT online documentation is not easy to navigate.

You have been smoking crack, haven't you? Despite it's unfamiliarity to those children raised on the Holy Bible of JavaDoc, the Qt documentation is a breath of fresh air when it comes to the dissemination of useful information. No other body of technical documentation anywhere in the Open Source world even comes close.