Qt 3.3 Released; Trolltech CEO on KDE, Linux, Qtopia, .NET/Mono

Trolltech today released Qt 3.3 which among other things features improved .NET support, full 64-bit support, IPv6 and backend support for two more databases. Also new is the -dlopen-opengl configure switch, which is very useful for prelinking Qt and KDE apps against the -PIC compiled nVidia drivers and support for Xft2 client side fonts on X servers without the
RENDER extension. In light of the release, OSNews features an article with TrollTech's CEO, Haavard Nord. Nord says that he sees Linux strengthen its position in both business computing and embedded systems, while he forsees Qtopia and Linux taking over PDAs and Smartphones in the next few years.


By Roberto Alsina at Wed, 2004/02/04 - 6:00am

You are right!

It's finally obsolete :-), the project did not get very far anyways (I did never really work on the code nor made any release). It was working though. But I am very happy that the trolls provide sqlite support directly in Qt.

CU Dom

By Dominik Seichter at Thu, 2004/02/05 - 6:00am

Congratulations to Trolltech !
I hope they will release soon a Win32 noncommercial edition. Does anybody know about that ? I am too lazy to install Cygwin.

By Jochen Rebhan at Wed, 2004/02/04 - 6:00am

The new book "C++ GUI Programming with Qt" comes with Non Commercial Win32 Qt 3.2.1. As far as I know, this is the only place you can get it. I got the book for $39 at Amazon.com. The NC version is fully functional and not limited by anything but its non-commercial license.

By David Johnson at Wed, 2004/02/04 - 6:00am

Sounds like a great book. I'll have to buy it!

By David at Sat, 2004/02/07 - 6:00am

They have discussed a few times binding with either Portable.NET or Mono, but the fear of a possible Microsoft lawsuit on these projects has held off any plans to go for either (the Qt# project on Sourceforge is effectively dead). However, Mr Nord said that the legal issues are just a part; there are also some technical challenges which would make a well-supported Qt# environment difficult to create.

What are the challenges and why is qtcsharp dead? It doesn't say it's dead on Sourceforge.

By ac at Wed, 2004/02/04 - 6:00am

Qt# isn't dead, but I am no longer working on it. Marcus continues development though and he's had the support of some interested developers lately. I stopped working on Qt# after it became apparent (IMO) that it would never become a first class language for KDE development. This was due to a number of fundamental shortcomings in the C# CLR design and the C++ ABI as well as some other factors.

Bindings are *hard*. It is near impossible to devise a method to allow subclassing of Qt widgets (which is absolutely necessary for an OO language otherwise... what is the point?) because there does not exist a portable way to modify the C++ vtable at runtime. At least not without breaking the C++ ABI. The only other solution is to reimplement every virtual function in KDE/Qt and provide hooks. This is a big bloated ugly solution IMO. This is what PyQt, PerlQt, RubyQt, JavaQt are all doing AFAIK.

Add to this the fact that the C# CLR does not allow custom marshalling of C# properties get/set accessors (not to mention it doesn't allow one or the other to be virtual, ie the get accessor can't be virtual if the set accessor isn't), the possible future legal problems with MS patents, the fact that C# delegates are inferior to signals/slots, the fact that we're tied down to MS design decisions and core API's ... and I've decided to look elsewhere for a solution.

Marcus is still working on Qt# though and others are more than welcome to help him out.

By manyoso at Wed, 2004/02/04 - 6:00am

Thanks for the info. I have been wondering what is up/not-up with QT# for a while.


By brockers at Wed, 2004/02/04 - 6:00am

Thanks for the update. So I guess C is a win for GTK afterall and that GTK# has a bigger chance to take off.

By ac at Wed, 2004/02/04 - 6:00am

If you count the integration of .NET and the usage of Mono and GTK# a 'win'. If all that is important to Gnome, Ximian, GTK and others then all power to them. Most of us would just like to get things done, so that's where I think the big 'win' is.

By David at Wed, 2004/02/04 - 6:00am

Probably; however, GTK# (and Qt#) aren't interesting, but their implementations of Windows.Forms are.

By anon at Wed, 2004/02/04 - 6:00am

Not really. Windows.Forms all depends on Windows compatibility and WINE unfortunately.

By David at Wed, 2004/02/04 - 6:00am

You're right, GTK# isn't interesting, but I'm pretty sure they're (mono project) doing their own C# UI toolkit built on SWT, which on Linux of course is built on Gtk+

By David Walser at Thu, 2004/02/05 - 6:00am

" Bindings are *hard*. It is near impossible to devise a method to allow subclassing of Qt widgets (which is absolutely necessary for an OO language otherwise... what is the point?) because there does not exist a portable way to modify the C++ vtable at runtime. At least not without breaking the C++ ABI. The only other solution is to reimplement every virtual function in KDE/Qt and provide hooks. This is a big bloated ugly solution IMO. This is what PyQt, PerlQt, RubyQt, JavaQt are all doing AFAIK."

Yes, you're right bindings are a hard problem. But we have a solution to the problem of language independent virtual method callbacks already - the SMOKE library. As long as every language binding doesn't try and reinvent the same sort of thing it is not a 'big bloated ugly solution'. Every binding can link to libsmokeskde.so (built in kdebindings/smoke/kde), and once loaded in memory they all share it. Ruby and perl use it at the moment but other languages are quite possible eg java and C# using their proxy classes. The memory occupancy of the language dependent bit of a binding is quite tiny compared with the common SMOKE library.

To use SMOKE with C# it needs to use a custom RealProxy class, and I initially tried dotgnu but that class wasn't implemented yet. So, I've been playing with mono 0.30 for the last couple of days - great fun - got 'hello world' working! But writing custom RealProxies doesn't seem very well documented at all, and I'm still messing with that.

-- Richard

By Richard Dale at Wed, 2004/02/04 - 6:00am

Very interesting! You da man! Thank you for making KDE bindings rock hard. :)

By ac at Wed, 2004/02/04 - 6:00am

Yes, I know Richard and I'm glad that you and Ashley are working on this. However, for me, I think SMOKE and the bindings that rely upon it will never be a first class language compared to C++ for KDE/Qt development. The overhead of binding each and every virtual function is ugly to my personal aesthetic. However, if this were the only hurdle for a C# binding it wouldn't bother me as much... but this isn't the case. The other problems still apply.

By manyoso at Wed, 2004/02/04 - 6:00am

The low-level programmer in me finds virtual functions in general to be a bit scary. On a Pentium 4, it takes more than 50(!) clock cycles to call a single virtual function. I doubt the bindings add more than 50% overhead to that. But in the end, its really not a bottleneck, so the programmer doesn't care either way :)

By Rayiner Hashem at Wed, 2004/02/04 - 6:00am

Virtual functions are the entire key to Object Oriented programming. The whole scheme doesn't make sense without them. As such, they are of pivotal importance in any binding project for an OO language. From a bloat standpoint, the extra thunks required are not as much a problem as the memory requirements for embedded systems. Even this isn't so great a problem, but it insults my aesthetic sensibilities as a mickey mouse solution for runtime link compatibility. So I'm looking elsewhere while others can continue with the binding efforts.

By manyoso at Wed, 2004/02/04 - 6:00am

Objective-C doesn't have Virtual Functions and its OO Paradigms are doing just fine. If you mean virtual functions within the C++/KDE realm than yes.

By Marc J. Driftmeyer at Thu, 2004/02/05 - 6:00am

All Objective-C methods are effectively virtual!

You just don't specify it because you have no choice...

By Adrian Bool at Thu, 2004/02/05 - 6:00am

Of course, 50 clock cycles on a 3Ghz P4 is just 16 nanoseconds. An uncached memory access probably takes more time.

By Henrik at Thu, 2004/02/05 - 6:00am

A KDE perl, ruby, python program or whatever is mainly calling the qt/kde libs which are written in C++. They are all actually quite fast, unless you want to write a fast graphics app perhaps. Nothing as slow as Sun's java Swing.

"The other problems still apply."

Please explain what these are?

-- Richard

By Richard Dale at Wed, 2004/02/04 - 6:00am

Yer, thanks for pointing that out. I have seen Smoke but haven't had the time to read about it.

By David at Wed, 2004/02/04 - 6:00am

I'm wondering, what the "possible future legal problems with MS patents" you mentioned are about. What patents are you referring to and which part of the Qt# or Mono world are they (possibily) affecting?

By Andreas at Tue, 2006/08/08 - 5:00am

It is late in the ballgame to post this but here goes anyway:

With all the latest news about M$/novel and now M$/linspire, it would seem the original poster's insight about 'legal ramifications' were plausible, and I also saw it coming; to think we still have no idea 'what' the infringments are it could all be FUD I realize but why so far two linux distros have signed onto this agreement without complete disclosure baffles me...and to think opensuse would not let in some non-oss ( linux maintains nvidia blobs are NOT a kernel infringement, BUT what does he know ??? ) but are willing to sign away to non-disclosure about something as important as copyright ;00

I noticed also that fedora pulled Beagle due to memory problems so Im curious to ponder what other mono components are causing instability....at times like this kde is looking brighter in my eyes and maybe linus was right afterall....

Does kde still not use mono or anything else deemed possible M$ infringementes ?


By neighborlee at Sat, 2007/06/23 - 5:00am

I'd like to know what this possible Microsoft lawsuit is that KDE is likely to face, that Novell is not.

Please when are we going to have a QT based mono c# environment. I really dislike the GNOME widgets, especially the combo boxes which have a tendancy to take over the entire screen, when they have a lot of data in them.

By tracyanne at Sun, 2006/09/03 - 5:00am

I read at the Hbasic(hBASIC.sf.net) site that the author also wants to integrate with the .net.

But what about patents?

By gerd at Wed, 2004/02/04 - 6:00am

There are many people, like Alan Cox, who have come out with Microsoft's threat of patents over Mono with .NET.

Microsoft do not use patents against competitors. They use technology. Remember DR DOS and that lovely error message you got when you tried to run Windows on it? IBM also played the same stupid game for many years. That's what Microsoft are about. Gently shifting goalposts to the point where people say "Oh, it doesn't work" and accept it. You just can't go around suing all and sundry. Where do you start? Better trap people with the technology thing that they can't understand or do anything about.

Microsoft won't use patents (not unless they're desperate :)) but they do like people to get scared and start talking about them. People like Alan Cox (although it isn't restricted to him at all) unwittingly do Microsoft's work for them :).

My problem with Mono is that it will simply be perceived by all the Windows developers out there as a way of getting MS .NET applications up and running on Linux and other platforms. It will not be perceived as a viable alternative, as Qt has the real potential to do. If MS .NET applications stop running with Mono, Mono instantly becomes a non-entity. No one is interested in GTK#, people will want to know if Windows.Forms will continue to work, and that very much depends on WINE and other hooks into the rather awful and extensive existing (and future) Windows API. With all the other things Microsoft are doing with .NET, like memory management (.NET has just not proven good enough for many 'low-level' fast applications like encoders, games and what not) and other ways Microsoft have of integrating .NET further into Windows, cross-platform compatibility is on a hiding to nothing. You need something nice, fresh and innovative that Microsoft cannot control. Hint: It's called Qt. Microsoft were so scared of Java because it was something new with a lot of buzz that Microsoft could not control in any way technologically. Of course Sun let Microsoft license it and they shoved Windows hooks onto it. Sigh... I think Trolltech has the Qt licensing for Windows quite right.

Microsoft will point to Mono and say "Look, there's an open source version of .NET, we are open" and use it as a means for publicising .NET (which hasn't took off at all). Over the course of the next few years they will integrate it further into Windows to the point where it will not be technically feasible to run any .NET applications under Mono. Many .NET applications are already a heavy bastard hybrid of x86/COM/MSIL compiled binaries to the point where I just don't see the point in it. .NET just seems to be Microsoft's response to the hype and popularity of Java :). Microsoft are panel-beating .NET into this one-size-fits-all development environment that just doesn't exist. Windows.Forms still depends totally on COM interfaces. Clever Microsoft. They always protect the user interface parts of their software. You can run purely functional COM servers quite happily on Linux and UNIX you know, but you don't do you?

Mono is creating some noise now because it is fashionable to say that you are developing an open source version of .NET. I'm not suggesting for one minute that this is why Ximian decided to do it, but it certainly seemed to get them sold :). We also had a lovely article about KDE supposedly moving to Mono and .NET as the main development infrastructure in the future. I wonder where that came from :).

I like the concept of .NET, and I like C# as a language a lot (it is important to separate the language C# from .NET - it can be implemented in different ways, and it is open after all) and Microsoft have obviously looked heavily at Java and tried to improve on it. However, I have a big problem in the way that any open source implementation will be perceived and the problems that running headlong into that hype will cause. I just think that the rational behind Mono is creating a huge dog's breakfast in the medium to long term.

The people developing on Qt# made the right decision to stop working on it, and they obviously didn't get sucked into the hype. As a developer I do like the .NET concepts and languages, so perhaps we can have C# and .NET, or something like them, and Qt together without the baggage of a .NET/CLR implementation in the future. In terms of cross-platform support I would have thought Trolltech might be interested in that kind of direction, particularly for GUI applications. Perhaps pure compiled binaries can be an option where needed, but a language runtime can be used where appropriate.

Qt# has not proven to be the right way for all this, but that's open source software. You've got to try things out.

By David at Wed, 2004/02/04 - 6:00am

You're not required to use Windows.Forms to make a .NET app.

Also, I thought they were moving away from COM and supposed to be using XML messages instead.

By David Walser at Thu, 2004/02/05 - 6:00am

"You're not required to use Windows.Forms to make a .NET app."

You can say the same thing about COM. But the Windows.Forms part is required to get GUI applications up and running. That is what people want.

By David at Fri, 2004/02/06 - 6:00am

> But the Windows.Forms part is required to get GUI applications up and running.

But that's what I'm saying, even that's not true.

By David Walser at Sat, 2004/02/07 - 6:00am

Which part of this are you not understanding? The implementation of Windows.Forms on Windows hooks very heavily into COM and the existing Win32 API. If you want to use MS.NET and use Windows.Forms here, you will, albeit unknowingly, be using the existing Win32 API. Yes you can use GTK# with Mono which gets around those problems, but people will not be interested in that.

Should you wish to get your compiled MS.MET applications up and running on Linux and Mono (which people will just expect to happen) you will have to deal with all the problems that entails. To get Windows compatibility this is what is required. Why do you think that WINE is required to get this working with Mono?

By David at Sat, 2004/02/07 - 6:00am

Right, but you don't need Windows.Forms or GTK#. The mono people are making a cross-platform GUI API that will work just as well on Windows as on Linux, based on SWT. You can make full .NET apps using it, a lot of the stuff in .NET is not tied to what GUI API you are using.

By David Walser at Sat, 2004/02/07 - 6:00am

Yer, but that wasn't wuite what I was getting at. Anyone using .NET on Windows will be using Microsoft's .NET and their implementation of Windows.Forms, not the GTK# or SWT options. When you look at it this way you have to ask what the point of Mono is at all.

However, I do agree you can do a lot of functional things with .NET/Mono on non-Windows platforms that you could actually do with COM, but no one really did. This may be a good idea, but my problem was with the way that it would be perceived by many people, and how a lot of the Windows-specific stuff would be handled in the future. This may mean breaking any kind of compatibility permanently. I would love to be proven wrong.

By David at Sun, 2004/02/08 - 6:00am

You have a very valid point.

Mono does provide at least the option to developers that want to use .NET but also are concerned with portability. I guess that's really the whole point.

It doesn't seem it'll really let end-users run any .NET app under the sun, so Mono's usefulness is limited by how much they get the word out, and how much mindshare they get.

By David Walser at Sun, 2004/02/08 - 6:00am

No they're not. They may look as if they are, but they aren't. You aren't familiar with Microsoft's history are you?

By David at Sat, 2004/02/07 - 6:00am

care to elaborate instead of just showing off?

By David Walser at Sat, 2004/02/07 - 6:00am

Just because Microsoft hasn't sued people over use of their patents doesn't mean they won't, or can't. In fact, if something like Mono ever really threatened Microsoft's continued existance, you can be sure they'd pull out their patents and start shutting down their competitors. There are two reasons why they won't right now. First is the ongoing anti-trust problems they've been having. Driving your competitors into the ground via patent lawsuits would only make them look guiltier. The second is for their public image in relation to those anti-trust problems. Using the courts to take out their competitors will only make people trust them less. Right now, it only makes business sense to use those patents as a weapon when threatened by other people who hold patents. Without a world-wide, perpetual, transferrable, royalty-free license from Microsoft to use those patents, I'd be wary of using technology embodied in them, especially knowingly.

By Chad K at Thu, 2004/02/05 - 6:00am

US PATENT Application program interface for network software platform
An application program interface (API) provides a set of functions for application developers who build Web applications on Microsoft Corporation's .NET.TM. platform.


Ms tries to patent .NET

FFII site on MS

Gates Says SCO's Case Against IBM Will Harm Linux’s Commercial Prospects

Ms applied for .Net patent

Note: There is a planned EU legislation "IPR Enforcement" Directive (unrelated to swpat directive) that will make a patent infrigement a criminal act. The voting will be very very soon.

By Andre at Sat, 2004/02/07 - 6:00am

This has to be one of the most astute commentaries on the whole .NET/Mono situation so far, and a refreshing contrast to the breathless ".NET is the new sex" articles and opinion pieces from sites like OSNews.

If the Mono crowd wanted to have a virtual machine environment endorsed by a big corporation and with some momentum, why didn't they just make a go of improving Java technologies? Is it because the people at the Mono "top table" have some kind of Microsoft envy? Certainly, the various arguments about Java's "locked down" status are mere distractions - there's Java support in GCC, and various Java derivatives and research projects abound, albeit without using the Java trademark. And whilst there might be some kind of patent threat from Sun, it pales in comparison to the measures Microsoft have in their anti-competition arsenal.

And the point about Mono being seen by Microsoft shops as an excuse for continuing their dubious ways whilst holding up a banner of supposed platform independence could hardly be more accurate. There are hordes of coders whose job involves hitting the right buttons in Microsoft Bullshit Studio, and loads of companies who perversely insist on Windows as a development environment, even when they're targeting Linux or Java platforms. Mono just gives those kinds of shops a figleaf to sell their services where cross-platform stipulations exist in the contract they're bidding for, only to hawk Windows licences later when their code won't run optimally or properly on non-Windows platforms.

By The Badger at Thu, 2004/02/05 - 6:00am

- Qt 3.3 adds support for the GNU C++ compiler on Windows (MinGW gcc)

very, very nice

By ac at Wed, 2004/02/04 - 6:00am

how can I download this GNU C++ compiler for widows

By ehab at Thu, 2004/04/08 - 5:00am

I want to download GNU C++ compiler.

By Mark at Tue, 2005/09/20 - 5:00am

i want to dowmload GNU C++ compiler

By khushi at Thu, 2007/03/08 - 6:00am

I want to download this compiler for my educational researh work.

By Choy Ken Keong at Tue, 2007/04/24 - 5:00am

Iwan to download this compiler

By Mark at Tue, 2005/09/20 - 5:00am

how to download it. please provide the link immediately freeware

By ravi at Fri, 2008/11/07 - 6:00am

How to download

By Mark at Tue, 2005/09/20 - 5:00am

I would like to have the compiler for my educational reseach work

By Choy Ken Keong at Tue, 2007/04/24 - 5:00am