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

It Sounds Nice

[Jeagoss]

but, is it absolutely essential? In a time where code needs to remain compatible due to the large amount of projects that are depending on that code, huge architectual changes implemented in a large number at one time will just show that the project wont get used for quite a while. It will take time for developers to start supporting the new format, which will leave end users wanting.

Re:It Sounds Nice

[Overly Critical Guy]

Why are Linux users so afraid of change? It's the very reason we suffer through so much legacy compability to slow things down.

I welcome any sort of innovation. People will update their apps to meet any changes.

Re:It Sounds Nice

[ded_guy]

I dunno--sometimes things have to be broken to make them easier, faster, or more flexible or to allow for future growth. Or sometimes just because there is a Better Way. Look at the breakages going on in Perl 6.

Re:It Sounds Nice

[Jeagoss]

I'm not saying change isn't good. Change is very good. The thing I see here is they aren't only implementing 5-6 new features and a small architecture change. Yes, they are trying to maintain source compatibility, but the style of coding is just far antiquated. Personally, when I write code, I implement a new feature, get it working very very well, and then move on to the next feature. This leaves room for other projects to implement the new feature, and start using it, while I then move onto the next feature. It proves to be a very stable, dependable method of coding. I'm not saying everyone should code this way, and I'm definitly not saying I'm better than everyone else. Rather, I am giving my unwanted $0.02. Coding in such a syle really lets people move forwared, in a very steady pace. Remember, the rabbit didn't win the race. The turtle did cause he was very steady and persistant.

Re:It Sounds Nice

[Anonymous Coward]

no funney here

Re:It Sounds Nice

[Anonymous Coward]

Moreover, backwards compatibility has caused a some of the most braindead "features" (drive letters, CRLF autoconversion, dual 8.3 / normal names, etc.) of certain, um, other OSes. If you can improve something and keep compatibility, great, but if you can't, by all means, improve it anyway.

Re:This is what I really want from Trolltech.

[AugustMoon]

Big deal. There is no law against having your stock owned by questionable companies. Furthermore, no publicly traded company can really control who buys their shares. They are publicly traded, any one can buy or sell the ownership.

It doesn't automatically mean Trolltech inherits all the vices of every one who owns shares.

I would not be worried or even morally concerned until Trolltech's business decisions go south. Minor share holders don't dominate a company. Even 5.7% isn't a lot.

Re:This might mean something to me

[Bingo Foo]

Their licensing scheme doesn't "suck." It's just incompatible with your goals, i.e. a free toolkit which you can use to create salable apps. If you don't like it, you can:

1. Buy a Qt commercial developer license
2. Release your own apps as open source
3. Use a different toolkit

It sounds like you have chosen #3. I'm sure the people at Trolltech are able to sleep well regardless.

QT4

[SlayerDave]

I have recently spent a good deal of time programming with QT3. While QT is the best C++ GUI library and application framework, I think it needs some improvement. Here are my gripes, in no particular order.

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. While not strictly illegal, the use of the SIGNAL and SLOT macros, along with the Q_OBJECT macro, are not very good techniques. Specifically the reliance on macros to achieve basic GUI functionality violates a key principle in Meyers' "Effective C++", namely avoiding reliance on the preprocessor.

Second, several GUI widgets do not have a proper separation of data from view. I am thinking specifically of QTable and QListView. A better approach, from an OO design perspective, is the one taken in Java Swing. The JTable and JTree provide a nice mechanism for separating the data model from the GUI display. I find it obnoxious to have to subclass QTable and build-in data model methods to achieve results that would be cleaner under a Model-View design paradigm.

The QT online documentation is not easy to navigate. They should take a lesson from the Java API docs and reorganize the QT docs along those lines.

Re:QT4

[fault0]

> The QT online documentation is not easy to navigate. They should take a lesson from the Java API docs and reorganize the QT docs along those lines.

Wow, I've found the Java API docs extremely hard to navigate.

Perhaps that's because of the bloat (in terms of classes) of the Java API, though.

Re:QT4

[TomorrowPlusX]

Let me tell you something about the model-view-controller seperation: it is the main reason swing and mac os x's cocoa are so damned slow for certain tasks. ( try dragging the vertical scroll-bar in the files pane in ProjectBuilder sometime... )

I emphasise "certain tasks" -- my own experence is more with cocoa than swing but I can say with absolute horror that NSOutlineView and NSTableView are dog slow, thanks to the model-view-controller seperation. QT's TableView and QListView, as much less abstract APIs, hauled ass.

I know this from experience, having ported quite a bit of my own code from Qt to Cocoa in the past 8 months. I've had to redesign parts of the app's frontend to get around the fact that keeping tabular data refreshed was consuming something like 75% CPU time. Whereas it was a non-issue under Qt.

I'm not complaining: Model-view-controller design is by and large a Good Thing, and frankly, programming NSTableView via delegates is a dream. But it comes with a price.

My recommendation is that if you dissaprove of the QTable and QListView concrete approach, write an abstract model mechanism to wrap it. It shouldn't constitute more than a few evenings' work.

I'm not so sure its a good idea.

[HanzoSan]

I agree with you exactly, it sounds nice but why do we need to change an architectual change when the current QT architecture is the best there is?

Why fix what isnt broken? Especially when you are ahead of the curve and on the cutting edge? Why not polish what you have? Thats the exact problem Gnome has, they keep restarting and redoing everything and they get NO WHERE.

KDE 4.0 would be better if it were based on the current QT because it could be polished, if they instead have to rewrite alot of code for a port, this is going to slow Linux on the desktop, and for what? A tiny bit more speed? I want to be sure that the benefits outway the cost here. The cost being time.

Why turn KDE into Gnome?

[HanzoSan]

This is the exact problem Gnome has. They keep messing around under the hood and nothing changes from the user point of view, development is moving at turtle pace because developers who want to write gnome apps cant figure out what to use because some new bonobo/mono type thing comes out every 6 months.

Developers need stability if they are going to work on big projects, we need at least a few years before a big re-write. I cant develop for Gnome because everytime I try to start they change something.

Backwards compatibility is important

[ZorinLynx]

Sigh. I really hate to say this, but I must agree with keeping API's backwards compatible across versions of libraries.

I've been using Linux for years now, and one of the biggest annoyances is that software packages tend to be tied very closely to a specific version of a library. Without backwards compatibility, you sometimes need to have two or three different versions of the same library installed in order to use different applications.

When a library is used by a wide variety of applications, like Qt, GTK, libc, and so on, backwards compatibility should be ensured. Yes, this means the library may be a bit more bloated than it has to be, but the bloat isn't as bad as the bloat that results from having to install an ancient version of Qt in order to run an app that hasn't had active development for a few years.

This is coming from someone who doesn't do much software development; I just maintain a lot of systems and software libraries.

Re:Very nice. But they forgot one minor thing:

[Anonymous Coward]

Other than that, Qt is indeed the finest toolkit out there. It simplifies development a lot, and it fills the great void that exists in C++ libraries. It's really like the Java libraries or the .NET libraries, providing almost everything needed under the sun.

Except that it costs way more than the MS development tools or Java.

Trolltech ain't getting many developers because of their insane pricing. Not that I want it for free, just reasonable pricing.

Shame because it is a decent cross-platform kit.

Re:Here's what I expect

[bongoras]

"There's nothing to stop Troll Tech from becoming unreasonable in their licensing demands... crippling all commercial KDE development. Since KDE is a desktop environment, commercial development is pretty important."

Yes there is, it's called the GPL. If TrollTech decides to do something loathsome in a future release of Qt, the previously released versions will still be there under the GPL, and anyone who wants to will be able to modify it, fork it, etc to their hearts content.

The GPL is what ensures that the freedom in free software -- both free as in beer and free as in RMS -- STAYS free.

Re:Here's what I expect

[be-fan]

So let's see. You want to use Trolltech's excellent toolkit, without paying them for it? Great... Hell, according to the FSF, stuff like this is supposed to be GPL'ed! Why do you think the LGPL is called "The Lesser GPL?" RMS says that "when a library provides a significant unique capability" it should be released under the GPL. Qt is one of the best GUI toolkits out there. Its a competitive advantage for free software projects like KDE to have it be GPL rather than LGPL.

Re:What I would like to see..

[RzUpAnmsCwrds]

"One of the advantages of Qt is that it provides a common interface to X-Windows, MS Windows, and Mac OS GUI programming."

Thankfully, GTK+ also does this. Gaim/Win32 is proof of that. With the new Wimp skin, GTK+ even matches the Windows look, for the most part.

Of course, there are also QT apps that I enjoy on Windows. MySQLAdmin, for one.

Re:Here's what I expect

[be-fan]

They *can't* do that. The Free Qt foundation (made up of two members of TT and two members of the KDE Project) ensures taht Qt will always remain free. If TT goes away, or decides to discontinue work of the Free edition of Qt, the latest version automatically becoms BSD licensed.

Re:Wrong...

[10Ghz]

The absolute success of KDE means that Troll tech will have a monopoly over commercial entrance to the Linux Desktop. Given that, why should anyone want KDE to become a standard desktop?

Because KDE is superior to the alternatives? And if you write free software, you don't need to pay one dime. I fail to see the problem. And if TT starts to abuse it's power, users would migrate to other toolkits.

Yes, I recognize that other toolkits can interact with the KDE environment, but if you need to use other toolkits or explain why Troll tech can exact a fee, why even support KDE as a standard desktop?

If you can't recoup the cost of Qt-license, then you should REALLY reconsider your desision to write closed, commercial software, since there obviously isn't that much demand for it.

It's not the money itself, it's the long and complex explanation as to why purchasing would have to be enaged to develop for a "free" software platform

If you write free software you don't have to pay. If you want to write closed software, you have to pay. I fail to see the problem. WHy should you get the right to write closed software but you want to deny TT the same right? If you use their tools for profit, you need to pay them, IMO that is fair.

Win32 doesn't even have this problem, and Gtk certainly doesn't have this problem.

Then use Win32 or your precious Gtk, I fail to see the problem.