Trolltech today released Qt 3.3 which among other thingsfeatures 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.

Comments

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.

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.

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.

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.

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.

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

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.

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 :)

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.

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.

Hi!
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?

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 ?

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.

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.

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?

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.

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.

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.

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.

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.