On Monday, OSNews had the pleasure of talking face to face with Trolltech‘s CEO and founder, Haavard Nord. Mr Nord discussed with us the new features found in Qt 3.3 (download, changes, announcement), Qtopia and the arising market of Linux in mobile phones as well as in the business computer market. Update: ITManagersJournal hosts a Trolltech article as well.Qt 3.3
The new version is backwards compatible with the previous Qt 3.x releases and it adds support for the .NET Windows platform. Developers will be able to write Qt code using any .NET-supported language and will also be able to embed Qt elements in other programs. Other Windows changes include full support for XP’s Style and theming while a version of ActiveX for Qt, ActiveQt, also sports improvements. The other major new feature on Qt 3.3 is full support (tested and supported) for 64bit platforms, including Opteron, Itanium and Apple G5.
Other new features include support for IPv6 and backend support for two more databases, SQL-lite and Borland Interbase. The Macintosh version now has support for fully transparent windows, while there have been some locale additions and changes, while QSA 1.1 features a number of improvements.
Qt/Linux discussion with Haavard Nord, Trolltech’s CEO
Mr Nord discussed a number of issues of broad computing interest. He told us that despite what some people say, X is good enough to promote the Linux desktop and it’s getting better and better, and with time will close the gap to Windows. He believes that Linux already works well in the corporate/business market (e.g. in China, Germany, some schools already utilize Linux) and that by the Longhorn release in 2005, Linux will be even more fit for the competition. He foresees though that Linux will have mostly have problems expanding with gamers rather than with normal home users.
Three years ago there were only 3-5% commercial Qt developers developing for Linux, but now this number is up to 40%. This has made Trolltech shift focus towards Linux as the main “Unix/X11” platform supported by Qt, along to Windows and Mac. While platforms like Solaris, IRIX, *BSDs, HP-UX and AIX are still supported, Linux is now the main X11-Qt focus. Additionally, he noted that while a port of VxWorks or QNX could be possible if these companies were interested in a port (for the right amount of money of course, as maintaining these ports is costly), their main focus will continue to be Linux in the embedded systems, and Windows/Linux for workstations.
It is well known that the main “application” of Qt on Linux is KDE (many of the core KDE developers are Trolltech employees), we were told that Trolltech has no desire to control the popular desktop project, but to peacefully co-exist and let it evolve freely. In the meantime, Trolltech continues to work for full interoperability with GTK+ in many levels.
Mr Nord noted that Trolltech works pretty closely with Apple (Apple which seeks more application support from Windows developers and so they are happy to feature another C++ API in their platform). There is at least one developer (out of the 87 Trolltech employees) working actively with Apple at Trolltech’s offices in Palo Alto, CA, USA.
Trolltech is definitely hot about .NET on Windows but they are not so hot about it on Linux. 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.
PDAs and Mobile Phones
Qtopia Phone Edition is derived from Qtopia for PDAs, and while a lot of code is the same, the infrastructure, features and hardware support is different. Trolltech is expected to have a new Qtopia UI for mobile phones out in a couple of months (minimum supported resolution is at 176×208). Trolltech would like to stay “application-agnostic” on their embedded targets, and so they won’t specifically pursue ports of Qt applications, in order to leave the field open to third party developers. For example, they won’t specifically pursue porting Konqueror as there are already Opera and Access’ NetFront web browser ports running on top of Qt.
Mr Nord told us that he is happy with the way Qtopia is placed in the market because vendors currently don’t want to license the whole Symbian proprietary system (Qtopia runs on Linux and so the system underneath is open) while at the same time they decline Microsoft’s offers as they don’t want to strengthen Microsoft’s position in the phone market. This opens the doors for Trolltech and Linux to get into this market fast: some Linux phones are close to release in China, and very soon in Korea and Japan. In two years Mr Nord sees these phones in Europe and after that is USA’s turn.
We asked Mr Nord when he sees today’s Smartphones (just 3% of the mobile phone market today) becoming common hardware and running Qt and Linux and he said that this time is around 2007 or 2008. By that time, he said, most phones will be shipping with 8 MB Flash and so Qt should run in most of them easily.
Mr Nord also spoke of Java on phones and he already sees a trend of phone OEMs getting away from Java because either the VMs are just not fast enough, interoperability issues with different J2ME versions, UI problems, etc.
Qtopia Phone Edition will feature special extra function calls so that developers would be able to call bluetooth, camera and other hardware functionality through Qt, hence making portability across different phone versions or models easier. Additionally, it will include new usability features, especially concerning the phone’s button usage making the usage easier and faster.
Mr Nord told us that Sharp is now the No1 PDA provider in Japan selling Zaurus with Qt/Embedded, however he sees the PDA market declining overall, giving way to affordable SmartPhones that have PDA capabilities (or PDAs with full phone capabilities, high resolutions — a new emerging kind of devices that will be more common in 2-3 years).
If they’ve got a member of staff working at Apple, wonder why they haven’t got the OS X look ‘right’ yet.
Hope the final release of 3.3 will fix the anomalies in hte OS X theme.
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
I’d be interested to know exactly what technical challenges were involved with a proper QT<>Mono binding. If the people at GTK can do it for free and in their own time, why can’t Trolltech manage it?
The Trolltech employee responsible for Qt/Mac is not working at Apple, but he is working with Apple when needed. There is a difference.
I did mention to Mr Nord that Qt/Mac doesn’t look exactly like Panther does. I am sure new updates will feature some work on this issue.
I dont byu the declinging of java on phones. here in the euroland, java on phones is on the increase.. j2me is on the up and up. symbian + palm is on the up. havnt seen a QT based phone yet on the highstreet…
“If the people at GTK can do it for free and in their own time, why can’t Trolltech manage it?”
Ask yourself, how big is the market for .NET developers on non-Windows platfroms and remember that TrollTech is a company and wants to be profitable.
BTW, if there is interest people can do a Qt/Mono binding in their free time too, but seeing that Qt# is dead shows us that there is not much demand for such a thing. I think Mono is still good two years behind MS.Net and still has a long way to go before it is ready for big enterprice deployment. I am sure if Mono is more mature and there is demand then a Qt/Mono binding will appear.
> but seeing that Qt# is dead shows us that there is not much demand for such a thing.
I think, one of the reasons, why Qt# is dead, is the license-mistake by Adam.
Qt# is licensed under the GPL (!) without any other license (so, it is not a dual- or trial-license) and without special exception. And Qt# is a library!
Qt for example is GPL, too. But it is also under the QPL. And if you want to use it in closed-source programs, you can buy a license for this.
GNU-Classpath on the other side, is only GPL. But it have special exceptions. Have a look at
http://www.gnu.org/software/classpath/license.html
But Qt# is only GPL-licensed. And Adam Treat don’t saw the need to change the license.
So, Qt# is for a lot of projects lost code.
You can’t use it for closed-source programs nor for OpenSource-programs, which are GPL-incompatible.
Another problem was that Qt# was built on top of the C bindings for Qt. That was quite a hack, not a clean solution IMHO.
> Another problem was that Qt# was built on top of the C bindings for Qt.
But I think, this was not the main-problem.
If I remember correct, he have planned to delete the detour over C and wanted to find a direct way.
This is a problem, which have Mono, too. Because there existing a lot of programmer, which want to use C++ libraray with C#.
So, I think, that the problem with the C-bindings, are not the reason, why Qt# died.
I think you’re right Eugenia. To solve this in a clean way, Mono should have a Managed C++ compiler, a thing not trivial to implement.
I, for once, would love to program in KDE with .NET.
“Another problem was that Qt# was built on top of the C bindings for Qt.”
Maybe I am wrong, but is it even possible to call directly C++ methods from within Mono? I think the additional C layer was required.
he already sees a trend of phone OEMs getting away from Java because either the VMs are just not fast enough, interoperability issues with different J2ME versions, UI problems, etc.
Last year I did a bit research to determine how much work it would be to create and support a small client app (to enter some data) running on commodity cell phone.
The options were Java VMs of different J2ME versions and the symbian platform.
At least the older J2ME standard (MIDP 1 or such) had less features to offer than C++ apps running on the symbian OS.
It was also not possible for me to determine, what kind of platform the cell phone vendors would be offering in the futures.
I was able to look at the present bunch of phnes, with
some phone having only a Java VM, some (mostly business phones) also featured symbian support, all I saw seemed to feature the older J2ME standard.
All in all they rather targeted the market of gaming, than providing some development platform for serious apps.
I could not make out a roadmap, so I could not guarantee the product would be able to run in say 2 years from now.
In the end the project did not get realized.
So what he says is not too surprising to me.
However I don’t know how the situation is at present.
Double buffering will debute in this release?
Thanks!
Andre
ftp://ftp.trolltech.com/qt/source/qt-x11-free-3.3.0.tar.bz2
http://www.trolltech.com/developer/changes/changes-3.3.0.html
<snip>
The Interbase plugin also works with Firebird, the
open source version of Interbase.
</snip>
Great stuff. For you that haven’t tried it..Firebird is coming along very nicely.
He is giving hopes to X, that’s a good news, Im one of the persons who thinks X needs some code cleaning but like he said, X is getting better.
I dont see why they would want to pursue this, ive found python + pyQT to be the most productive development system i have ever used (moreso with pyKDE).
I agree, X is really, really good. The only people i know who think otherwise just simply dont understand how it works, and that alot of its ‘apparaent shortcomings’ are nothing more than problems with whatever toolkit is being used. It lacks some of the cool stuff OSX has (pdf rendering model, render to opengl) but all this stuff is on the way with projects like cairo (svg will prove to be better than pdf imho). The opengl stuff will give the potential for a lot of eye candy in the desktop department, which although is always useless is still nice to have, how long does it take to get bored of the genie effect in OSX?
On a side note i used Panther for the first time this week and must say i was _very_ impressed with the Expose stuff, i could see myself replacing virtual desktop usage with that. When we have an opengl rendering backend in X (i mean in terms of windowing, not just opengl support) this will be a really great addition to kde. Its probably doable now, im just not sure how it can be implemented in an accelerated way.
The problem was runtime overrides of C++ virtual functions. This was not feasible without subclassing every Qt class and reimplementing its virtual functions and providing a hook for C# classes to override. This is the way most bindings work and IMO it is horrendously ugly. Not to mention bloated for embedded systems. This combined with some fundamental design breaks with the CLR, the possible patent problems with MS led me to believe Qt# wasn’t going to be a full fledged first class citizen for KDE/Qt development. However, Marcus is still working on Qt# and has the support of a few other interested developers. I’ve talked with Haavard a few times and am keeping up to date with what is going on.
Yes, Eugenia, the reliance upon QtC was another pain although we were working on minimizing this. QtC wouldn’t have been so bad if we had control over its production and could customize it to our needs… which is something Marcus is working on right now. We were actually mangling the method function calls according to the gcc C++ ABI and were calling directly into the Qt C++ library. This worked ok, but also had a few problems.
Why must the cellphone manufacturers be so cruel? I was linux phones and I want them yesterday. Same goes for the hires pdas. North American public will embrace anything that gets heavily marketted at them. So just because they choose to market inferior phones and inferior pdas, they dont sell other ones as well.
Same goes for laptops..They choose to market shitty big laptops so there is no market for portable ones.
I’m just starting to play with laptop GPS solutions – mostly Windows proprietary (Streets and Trips, TOPO!) but I’m experimenting with Java open source (GPSylon), and want to try Linux (GPSdrive, see http://tuxmobil.org/navigation_gps.html for more). My next PDA will either have GPS built in (like a Garmin iQue), or more likely it will have bluetooth to communicate with a separate GPS (so PDA can velcro to steering wheel, GPS on top of dashboard). It would be great if I could consider a Linux PDA or Linux smartphone (though smartphones will probably have too small of a display).
So my question for Haavard would have been whether his company would consider (either starting from scratch or helping to bring a current solution such as qpeGPS out of alpha) developing a nice integrated GPS solution that would allow either open or proprietary map formats.
Dara
OEMs and carriers aren’t making phones for the greater good of humanity, they are doing it to make profit. If they have the feeling that they can make profit, they go for it. Otherwise they don’t. In the case of very advanced phones in the US, at the moment their perception is that there isn’t enough profit to be made.
(and, no, rolling out a cell phone isn’t nearly as easy as it seems).
The socket/slot mechanism could be written in any .NET language without ugly hacks like the moc, since .NET has much better reflection capabilities than C++.
It would be perfect to have a managed C++ compiler for mono. That way you could just compile the Qt library and all of KDE to MSIL. This would be a great advantage for the KDE project since there would no longer have to be binaries for each distribution/version/architecture. One set of binaries for all distibutions, all libc versions and all architectures.
But unfortunately Gnome will get there first. Most Gnome apps are written in plain C, and there already exists a C=>MSIL compiler (from the dotGnu project), so technically it would be possible to compile the whole of Gnome to MSIL and distribute a single set of binaries for all platforms.
This is IMHO the best chance GNOME has to become the dominant desktop. It’s really a pity, since I prefer KDE…
“The socket/slot mechanism could be written in any .NET language without ugly hacks like the moc, since .NET has much better reflection capabilities than C++.”
Signal/slot systems have been written in C++ without MOC or similar preprocessors (see libsigc++, Boost.Signals).
All it would take is one guy with a Comeau C++ license to recompile its object code (which is C) into MSIL.
I don’t expect anyone to bother, though, because you *do* need to change the way some things are done (like, say, screen drawing, and manual memory management).
Managed C++ is right now a subset of C++. Hell, last I checked it lacked even templates.
Are you insane? What good can come from this? What about all the 3rd party libraries (jasper, libjpeg, libpng, openGL) Currenlty kde (and i believe gnome too) release no binaries, its the job of the distributors to provide them. Its also not hard to build either kde or gnome on any supported platform (especially i386 linux).
[…]while at the same time they decline Microsoft’s offers as they don’t want to strengthen Microsoft’s position in the phone market.
I disagree. I would rather pin the problem on the fact that Microsoft is too inflexible in licensing their OS than any of their main competitors. Compare Nokia and Sony Ericson Symbian-based smartphones – both use the same operating system but other than actually using it, one wouldn’t know that at all! On the other hand, you can tell a Windows-based smartphone a mile away.
Competitively, it prevents mobile phone developers from distinguishing themselves, but however allows Microsoft to unite them under one common logo (the Windows logo). In other words, Microsoft is treating this market like they are treating the PC market – they aren’t the same ya know, Microsoft.
> Managed C++ is right now a subset of C++. Hell, last I
> checked it lacked even templates.
>
AFAIK you can write real C++ code containing templates, multiple inheritance, explicit memory management using delete etc. and target the MSIL instead of a real isa like x86. The resulting MSIL code makes heavy use of unsafe features such as pointers and is therefore not verifiable, but it runs on a MSIL VM.
Managed C++ is just a verifiable subset of real C++ that targets the MSIL VM.
Before you go on salivating about QT and .NET, please read the details (http://doc.trolltech.com/3.3/activeqt-dotnet.html).
As the article shows, QT does NOT have a native .NET component. In fact, they are peddling an activeX component. This means that use it from .NET, it needs to be called via Runtime Callable Wrapper (RCW) (a code block designed to interoperate with COM components). This means that there will be a performance penalty associated with the overhead of having to call the RCW, then the ActiveQT COM Object, which in turn calls the actual QT implementation.
That’s a lot of hoops to jump through and makes it a non-starter for 99.9% of windows apps. What they need is a native .NET version of their ActiveQT middleware, then will talk.
@Tom: You’re absolutely right. Python rocks for GUI development. If it had a good native compiler, I’d really see no reason to use anything else for GUI apps
Re: Qt & Mono:
I think the reason there doesn’t seem to be all that much interest in C# bindings for Qt is because C++ is really good enough for the job. One of the main reason Windows developers are so happy about C# is that their previous GUI APIs (MFC, Win32) sucked. However, Qt with C++ is an extremely nice API to program already. Many of the traditional C++ pitfalls (memory management, dangling pointers) are ameliorated by Qt. Qt widgets manage their own memory, and the memory of child widgets. Qt doesn’t encourage passing around pointers to things, but offers standard container classes, and makes many of its classes reference-counted or copy-on-write, so you can pass them around like value objects. For your own objects, you can use smart pointers which handle memory management automatically. Since the whole of the Qt API behaves like this, and the Qt API (especially with KDE) encompasses so much functionality, there is rarely a reason to have to drop down into fussing with pointers and whatnot. Thus, moving to C# just doesn’t seem are huge of an advantage.
So are we going to finally get a non-commercial or GPL Windows version so I can start programming PyQt again?
You *can* get a non-comm Qt for windows now, buying the book ($30 on amazon), but the PyQt guys are still undecided on supporting it.
You get a Borland compiler with the book, too, so you can at least use it for C++ con-comm development without much hassle.
It would be perfect to have a managed C++ compiler for mono. That way you could just compile the Qt library and all of KDE to MSIL.
One question. What the hell for?
But unfortunately Gnome will get there first. Most Gnome apps are written in plain C, and there already exists a C=>MSIL compiler (from the dotGnu project), so technically it would be possible to compile the whole of Gnome to MSIL and distribute a single set of binaries for all platforms.
The more the merrier as far as I’m concerned. As a programmer I’m interested in getting stuff done.
This is IMHO the best chance GNOME has to become the dominant desktop. It’s really a pity, since I prefer KDE…
Oh, the old “I love KDE but…” stuff. I don’t see how compiling Gnome to MSIL equates to being a dominant desktop, but there’s one born every minute.
I’ll pretty much agree with you on your points only to add that as other have stated, the QT# bindings were a major pain because of the whole virtual functions problem in c++. I’m not compiler wiz, but saw a couple posting by Adam(who was the first guy to work on qt#) on the GCC mailing list to see if anybody could give him any hints to go about. I guess if the ABI were stable, then you could’ve does some hackery with vtables, but like I said, I’m not compiler expert.
The KDE developers never had a problem with qt# or kde# bindings. There’s still a link to the qt# page at developers.kde.org. I’ll agree that c++ takes away many of the advantages that wrapping gtk+ up in a managed language gives you over straight c and gtk+, but I’ll say that writing little irc clients in c++ probably isn’t an optimal use of developer time, even though the KDE framework is great.
I’ve said it before many times, and Eugenia even wrote it up in an article – writing your average Gnome app(I’m not talking core libraries here) in straight c in 2004 reminds me of assembler programs i would talk to in 1997 that refused to migrate to c. To each their own obviously, but at some point you have to move on.
As far as win developers – year, I don’t think there’s a win developer on the planet that is going to lose sleep over the win32 api and MFC going the way of the Dodo bird.
I remember reading an interview some years back with the Troll Tech developers. One of the reason they started doing Qt was because they as C++ programmers wanted a GUI library that was native C++. They where unhappy about all the other options of that time being mostly bindings to C based widgets.
<P>
If Troll Tech went for C# bindings the Qt# would be somewhat of the opposite of the idea begind Qt in the first place.
<P>And besides, why pay to do commercial development with Qt# when its free with Gtk#? The arguments used in a C++ context for why to pay wouldn’t work for C# bindings.
I’d be interested to know exactly what technical challenges were involved with a proper QT<>Mono binding. If the people at GTK can do it for free and in their own time, why can’t Trolltech manage it?
Gtk+ is a C-based toolkit designed from the ground up to be bound to other languages (there are full, machine-readable API specs, for example). Qt is a C++-based toolkit that relies on lots of C++ features. That makes binding Qt to anything a challenge.
the possible patent problems with MS led me to believe Qt# wasn’t going to be a full fledged first class citizen for KDE/Qt development.
The only “possible patent problems” are over the .NET APIs, not over Mono or bindings of Mono to non-.NET languages. A lot of C# programming on Mono is based on the core C# APIs plus tons of existing open source libraries, which would not be affected even if MS’s patent was valid and even if they foolishly tried to enforce it against Mono.
Ask yourself, how big is the market for .NET developers on non-Windows platfroms and remember that TrollTech is a company and wants to be profitable.
Yes, and that’s a problem when many of the core developers for an open source project are working at the company that sells the same project commercially. The question that should be asked is: “would this be useful to developers and would it help other open source projects”. The question that’s being asked is: “if we do this, can we make more money”.
Eugenia,
I wonder why this article wasn’t posted as an interview to Mr. Nord. Instead it’s more like an article in 3rd person, like “Mr. Nord also said…”, “Mr. Nord noted…”, “We asked Mr. Nord about…”, ‘Mr. Nord also spoke of Java…”.
Don’t you think it would have been better to make a one-on-one interview instead and read what he has to say about different topics in his own words. IMHO, I think is better to see how the interviewee express him/herself, specially if he/she is a CEO or industry leader. It gives you a better idea of the person and how sharp is he/she.
Ernesto
I could not do it this way because I had to write down everything word for word and that would be pretty impossible in the one hour we got together. Instead, I just took notes and just had a broad discussion about things.