Thanks to KDE France, I have the chance to conduct a phone interview with Trolltech CEO Eirik Eng. If you have questions on Qt and Trolltech, now is the time to ask! I will harvest questions from LinuxFr, KDE France and of course here. A possible set of topics includes: the future of Qt, Trolltech's status as a company, Qt's market penetration internationally, competition with Red Hat and GTK+, Qt on MacOS X (ed: recent OSNews article). If you have any other ideas, please be quick to voice them as the interview time is imminent.

Comments

What makes you think that Qt doing the rendering is slower than Windows (or whatever) doing the rendering? I mean OK, on Window, USER may be using some sorts of undocumented hooks in GDI or something. But on X, there is no
fundamental difference between supposedly 'emulated' Qt approach, and what GTK+, which SWT uses, does. Yet Swing is slow and SWT is supposedly fast; and surely, the same approach that's nice and fast on X would still be nice on other UI systems? Sounds to me like you're taking a poor implementation, and are making conclusions about a whole class of architectures based on it, which is, well, a good way to reach wrong conclusions.

As far as most people are concerned, Qt is a native toolkit, as is GTK. Linux is a bit odd in having two, but hey, whatever.

Bear in mind there's nothing in "emulated" that says "slow", despite the name.

SWT vs Swing is just because Java is historically not fast at graphics and Swing is a bit of a dog (though in fact we use it at work and the latest versions are not so bad). In fact Qt is pretty fast (as is GTK relatively speaking, though GTK is hit badly by its usage of XRENDER).

I think the reason why Swing is so slow is that it is completely run under an interpreted language while SWT hands over all the hard work to the machine code to do. Why should an emulated toolkit be slower than the native if it uses the same primitive drawing routines? The only speed/slowness will come from the performance of the creation for the graphics to draw.

Java started as an interpreted language, but today it is a bit different story. Leading Java VMs employ JIT (Just-In-Time) compilation. That is, frequently used bytecode is compiled to native code on the fly and cached. This enables many optimizations (like in-lining). So today, Java performance is comparable with native software. I saw benchmarks where Java implementation (running on Sun's JDK 6) had outperformed GCC-compiled counterpart.

Did your friend respond to your suggestion that Qt would make porting easier (across *NIX, Win*, Mac, PDAs)? It seems like all of the arguments for MFC are only for features tightly tied to MS-Windows.

1. Qt can now use and provide ActiveX. There are thousands of ActiveX available so it should answer the need for diversity.

2. Using an external control is always risky:
. you don't know the quality of the code you use
. usually the code you use that way does not do exactly what you need so you end up spending a lot of time understanding it and customising it. As quick as writing it yourself.
. writing yourself the code gives you more control when you want to extend it

It has happened many times to my team that somebody picks up a control "hey, this guy did just what we need" and give after two day of trying to make it work the way they want (when it is not simply "make it work"). The quality of internet available code vary greatly from very bad to good.

Qt has become an all-included library no longer limited to doing GUI stuff but also offering backend support to databases etc. While doing so will Qt stay monolithic after 3.x or is a more modular design like separating frontend and backend or supporting extensions through plugins considered?

How do you feel about KDE developers now collecting/publishing patches in qt-copy/patches CVS module against Qt which didn't get included into Qt or a reaction when sent to qt-bugs@trolltech.com after a reasonable time?

I would like to know if there are any plans to implement some Base64/UUEncode classes for transparent {de,en}coding, perhaps based on QMemArray.

Since there is IMHO no real portable library supporting this and e.g. some of the KDE applications have got their own implementations, it would be really great to have something like that directly built into Qt.

Does Trolltech have any plans or work in progress for making Qt considering KDE as a platform like Windows (meaning using KDE file dialog and other stuff in Qt programs if KDE is installed) as once proposed by your Mathias Ettrich?

Actually, it is possible to do that in some convoluted way with current Qt, at least for widgets a couple levels inside a QMainWindow. The TOra database app does something like that with its toolbars... I had to fix a widget rendering bug @ Keramik with that setup, so I know it exists.. Don't have the code at hand ATM, though, may be I still have my test app at home, though..

Actually, it is possible to do that in some convoluted way with current Qt, at least for widgets a couple levels inside a QMainWindow. The TOra database app does something like that with its toolbars... I had to fix a widget rendering bug @ Keramik with that setup, so I know it exists.. Don't have the code at hand ATM, though, may be I still have my test app at home, though..

Hmm. Actually, it's not the only app that does that. KFileDialog uses
a (flat) toolbar. So does kcmprintmgr.

Are you aware of (and can talk about) known companies writing new consumer products or converting there current ones to Qt other than the recently announced Adobe Photoshop Album? Perhaps thanks to Qt's Motif integration offerings a Acroread Reader or Realplayer version with Qt interface?

My question:
C++ will not be forever, at least its use will decline as newer languages like Java and C# become more popular. Both languages allow platform independent programming, and even today they come with libraries and toolkits that offer even more functionality than Qt.
So what is TrollTech going to do? Will TrollTech try to find new markets? Which?

I have to agree with this. Java and C# replacing C++ is just typical hype. Before C#, it was Java and Delphi. Before Java, it was Delphi and Visual Basic that people claimed would draw people away from C++. When C++ became popular (early 90's) people were saying it would totally replace C, so why keep support for C in C++ compilers. Well, guess what. C is still around and in heavy use today, Visual Basic and Delphi are still around but have diminished in popularity, due to Java and C#. Cobol and Fortran are still in use today as well, even though most people seem to think they have died. And there are quite a few people out there who still write their software in assembly language (for the most part, though, they're embedded systems programmers). Java and C# will likely remain in use primarily in small software (embedded software for cell phones and the like) and for web-based projects. C and C++ will likely remain the languages of choice for work such as os kernel development and professional application development, as well as embedded systems programming. In fact, C++ is on the rise in popularity among embedded systems programmers due to EC++, the Embedded C++ standard which was finalized in (I believe) 2001, maybe 2002. C++ will not die, nor will C. They'll still be in use by the time we're all retired and grandparents (or great-grandparents even, if we live long enough). There is far too much code out there written in these languages for people (and especially companies) to just say, "ah, screw C++, I like (insert choice here) better, let's though out all our old code and start over from scratch in our new favorite language."

"ah, screw C++, I like (insert choice here) better, let's though out all our old code and start over from scratch in our new favorite language."

That, of course, is not the way it works. Will a significant number of new projects in Qt's core market (desktop and PDA/Phone GUI apps) use C++ in the year 2010? I don't think so.
It's quite possible that other projects, like Linux and the BSDs, may use C++ (or C+, like MacOS) then. But they certainly won't use Qt...

"Will a significant number of new projects in Qt's core market (desktop and PDA/Phone GUI apps) use C++ in the year 2010?"

Why not? Traditionally, embedded developers used C. They laughed at OO. But now the fad is Java in embedded devices, and the OO pariah has gone. Enter C++, with all the low level stuff that embedded developers like, and all the OO goodness of Java. Now that GNU and MS have *finally* decided to implement the C++ standard, I see C++ ready to take off in all markets, including embedded.

The first apps in Java and .Net are already out and support for these languages seem to become a standard feature, so it can be expected that support for them in 7 years will be very good. So why should anyone use a lower-level language?

Funny, the "first apps" for Java were out ten years ago. But the "first apps" for C++ were out twenty years ago. Support for Pascal was good seven years ago, and look where it is today.

Use whatever language you want to use, but don't make sweeping pronouncements about what the future will be like, because everyone who has done so in the past has been wrong.

Why should I use a lower level language like C or a mid level language like C++? Because I'm writing software that uses the lower and mid levels of the hardware. Show me a kernel written in .NET. Show me a GUI written in Java that doesn't call native C routines to perform the real work. My company produces hard realtime medical systems doing a heck of a lot of signal analysis. What language should I use?

Yes, C++ will be there forever, but its use will decline, just like Fortran's and Cobol's market share have gone down from >50% to a few percent in the last 25 years. Boost can't change the fact that C++ will be less productive than the newer languages. (I am not talking about the next year, but the next >=5 years when they have matured).

BTW, Stdlib+Boost is pretty pathetic compared to the breadth that the standard libraries of Java and DotNet offer. There's not even a XML parser or basic network support in the standard C++ libraries. Not to mention stuff like database/SQL, printing, HTTP/FTP, IPC/RPC, WebServices, support for directory servers, security (kerberos etc), cryptography, GUI, 2D rendering & image manipulation, 3D rendering, accessibility...