Linked by Eugenia Loli on Wed 4th Feb 2004 08:56 UTC
Qt 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.
Order by: Score:
Mac Qt
by Wee-Jin Goh on Wed 4th Feb 2004 09:31 UTC

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.

Qt# & Mono
by JCooper on Wed 4th Feb 2004 09:32 UTC

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?

RE: Mac Qt
by Eugenia on Wed 4th Feb 2004 09:34 UTC

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.

j2me
by he who replies on Wed 4th Feb 2004 10:11 UTC

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

RE:Qt# & Mono
by Anonymous on Wed 4th Feb 2004 10:13 UTC

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

Re: RE:Qt# & Mono
by Helena on Wed 4th Feb 2004 11:18 UTC

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

Re: RE:Qt# & Mono
by Eugenia on Wed 4th Feb 2004 11:20 UTC

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.

Re: RE:Qt# & Mono
by Helena on Wed 4th Feb 2004 11:31 UTC

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

RE: Re: RE:Qt# & Mono
by Tetsuo on Wed 4th Feb 2004 11:32 UTC

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.

Re: RE:Qt# & Mono
by Anonymous on Wed 4th Feb 2004 11:43 UTC

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

J2ME mess
by Marc van Woerkom on Wed 4th Feb 2004 12:07 UTC

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.



What about DOUBLE BUFFERING
by goddard on Wed 4th Feb 2004 12:31 UTC

Double buffering will debute in this release?


Thanks!

Andre

Firebird
by Fredster on Wed 4th Feb 2004 13:42 UTC

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

...
by Anonymous on Wed 4th Feb 2004 14:32 UTC

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.

Re: mono & QT#
by Tom on Wed 4th Feb 2004 14:33 UTC

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

RE: ...
by Tom on Wed 4th Feb 2004 14:39 UTC

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.

Licensing had nothing to do with it.
by manyoso on Wed 4th Feb 2004 15:09 UTC

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, the intermediate C library was another pain...
by manyoso on Wed 4th Feb 2004 15:13 UTC

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.

Linux phones
by Taras on Wed 4th Feb 2004 16:34 UTC

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

Re: Linux phones
by JBQ on Wed 4th Feb 2004 16:50 UTC

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

Qt and .NET seems to be a natural fit...
by tuttle on Wed 4th Feb 2004 17:26 UTC

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

RE: Qt and .NET seems to be a natural fit...
by /dev/null on Wed 4th Feb 2004 17:52 UTC

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

Re: tuttle
by Roberto on Wed 4th Feb 2004 18:00 UTC

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.

RE:Qt and .NET seems to be a natural fit...
by Tom on Wed 4th Feb 2004 18:01 UTC

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

On Microsoft's Windows Mobile Phone Edition
by rajan r on Wed 4th Feb 2004 18:06 UTC

[...]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.

Re: Roberto
by tuttle on Wed 4th Feb 2004 18:22 UTC

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

QT & .NET
by rizzo on Wed 4th Feb 2004 18:48 UTC

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.

Responses
by Rayiner Hashem on Wed 4th Feb 2004 19:08 UTC

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

Non-commercial license?
by Anonymous on Wed 4th Feb 2004 19:32 UTC

So are we going to finally get a non-commercial or GPL Windows version so I can start programming PyQt again?

Re: Non-commercial license?
by Roberto on Wed 4th Feb 2004 19:47 UTC

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.

v Kick Paul Yarro off the Board of Directors
by bucky on Wed 4th Feb 2004 19:49 UTC
RE: Qt and .NET seems to be a natural fit...
by David on Wed 4th Feb 2004 20:59 UTC

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.

RE: Raynier
by Roy Batty on Wed 4th Feb 2004 21:32 UTC

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.

Qt-to-Mono
by Anonymous on Thu 5th Feb 2004 07:52 UTC

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.

"possible patent problems"
by Anonymous on Thu 5th Feb 2004 07:59 UTC

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.

TrollTech and .NET
by Anonymous on Thu 5th Feb 2004 08:02 UTC

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

Interview
by Ernesto Marquina on Thu 5th Feb 2004 16:06 UTC

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

RE: Interview
by Eugenia on Fri 6th Feb 2004 19:35 UTC

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.