JUL
2
2003

Your Chance to Ask Trolltech

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.


By Sad Eagle at Wed, 2003/07/02 - 5:00am

Agreed.. the slowness of Swing isn't because it's not native, but rather the fact that it's slow.

Qt is much, much, much faster than Swing on Windows. It uses native themeing in XP.

Note that Microsoft themselves don't always use "native widgets". See OfficeXP for example.


By pret at Thu, 2003/07/03 - 5:00am

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


By Mike Hearn at Thu, 2003/07/03 - 5:00am

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.


By David at Sun, 2006/05/07 - 5:00am

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.


By JK at Tue, 2007/05/15 - 5:00am

> Qt is fundamentally an "emulating" toolkit, it does all widgets internally.

Only partially true on WindowsXP and MacOSX.


By tilt at Wed, 2003/07/02 - 5:00am

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.


By Andy Marchewka at Wed, 2003/07/02 - 5:00am

My responses as a Qt windows programmer:

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.


By Philippe Fremy at Wed, 2003/07/02 - 5:00am

> This, and the fact that you still need to license MS Visual C++ to be able to use Qt

No, only if you want to use Visual C++

I see four other qmake targets in the mkspecs dir of my Qt installation

Cheers,
Kevin


By Kevin Krammer at Wed, 2003/07/02 - 5:00am

Does Trolltech have any accessibility expertise which will lead to improved infrastructure in future Qt versions [keywords: AT-SPI (Assistive Technology Service Provider Interface), laws (http://developer.gnome.org/projects/gap/laws.html)]


By Anonymous at Wed, 2003/07/02 - 5:00am

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?


By Datschge at Wed, 2003/07/02 - 5:00am

Also, will Trolltech create a separate qlib that contains QObject and all other non-GUI utility classes from Qt, just like the Red Hat developers have separated out glib from GTK+?

This could be useful when developers want to do development with the Qt framework without having to link in all the GUI stuff.


By anon at Wed, 2003/07/02 - 5:00am


By Anonymous at Wed, 2003/07/02 - 5:00am

TinyQ is nice, but it just took the low-hanging fruits. More complicated things like the event loop or QObject are not included, since that would require relatively complex modifications.


By AC at Wed, 2003/07/02 - 5:00am

Yep, good question >>will Qt stay monolithic after 3.x or is a more modular design [...] considered?<<


By cies at Wed, 2003/07/02 - 5:00am

When can we expect to see QTopia, now based on the Qt 2.x series, move to a more recent version of Qt?


By André Somers at Wed, 2003/07/02 - 5:00am

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?


By Anonymous at Wed, 2003/07/02 - 5:00am

Hi,

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.

bye
Erik


By Erik at Wed, 2003/07/02 - 5:00am

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?


By Anonymous at Wed, 2003/07/02 - 5:00am

Yes, Very good question.


By Anonymous at Thu, 2003/07/03 - 5:00am

Id like to see "./configure --build-for-kde" or something like that :P

/kidcat


By kidcat at Thu, 2003/07/03 - 5:00am

No! We already had that in Qt 2 and it's the wrong solution. That way, you create a cyclic dependency (Qt requires KDE requires Qt...)

You need a different approach, which will probably lead us towards the need of a proper component model again. We plan to discuss that in n7y btw.

Cheers,
Daniel


By Daniel Molkentin at Thu, 2003/07/03 - 5:00am

ooops.. Brain-Bummer(TM) on my behalf :-/

/kidcat


By kidcat at Fri, 2003/07/04 - 5:00am

Philippe's previous interview from 2001 can be found at http://dot.kde.org/1001294012/
Another interesting one by LinuxPlanet: http://www.linuxplanet.com/linuxplanet/interviews/4673/1/


By Anonymous at Wed, 2003/07/02 - 5:00am

Interesting.

I want to know if Trolltech has offered QtAWT to Sun...


By anon at Wed, 2003/07/02 - 5:00am

Do you plan to finally bring Qt on par with all the other rendering APIs out there?
Writing vector graphics apps isn't really possible (integer coordinates,
no bezier postscript output, no alpha chanel etc etc).


By Lenny at Wed, 2003/07/02 - 5:00am

When will Qt get support for using QToolBar widgets in any widget other than the QMainWindow?


By nac at Wed, 2003/07/02 - 5:00am

That was reported as a bug ages ago and IIRC we got back a WONTFIX response.

Rich.


By Richard Moore at Wed, 2003/07/02 - 5:00am

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


By Sad Eagle at Wed, 2003/07/02 - 5:00am

>> at least for widgets a couple levels inside a QMainWindow

Yes, that's the whole problem.. it should be possible to use QToolBars in _other_ widgets/windows as well ;)


By nac at Thu, 2003/07/03 - 5:00am

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.


By Sad Eagle at Wed, 2003/07/02 - 5:00am

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

Not sure, but afaik those are not using a QToolBar.


By nac at Thu, 2003/07/03 - 5:00am

They're using a KToolBar which inherits off a QToolBar.


By Sad Eagle at Thu, 2003/07/03 - 5:00am

As far as I can see from looking at the docs the KToolBar doesn't support any widgets other than Q/KMainWindow either..

(and I still don't understand why KDE people thinK it's necessary to Kreate lots of dupliKate Klasses to Ket that silly K in widget Klass names, but that's another topiK :)


By nac at Thu, 2003/07/03 - 5:00am

Well, it obviously does, since I told you where it is used. What you need is a constructor
that takes a general QWidget*; which in turn calls to
http://doc.trolltech.com/3.1/qtoolbar.html#QToolBar-2
with mainWindow = 0.

And if you even bothered to look at the KToolBar and QToolBar docs for more than 5 second you'd see why there is
a KToolBar, since it's pretty obvious (hint: count the methods).


By SadEagle at Thu, 2003/07/03 - 5:00am

> and I still don't understand why KDE people thinK it's necessary to Kreate lots of dupliKate Klasses to Ket that silly K in widget Klass names, but that's another topiK

Because people don't want to wait for similiar functionality to appear in Qt (if ever?!)


By lit at Thu, 2003/07/03 - 5:00am

Well, of course it would break the API/ABI so that WONTFIX is pretty logical.. but perhaps it could be done for Qt4?


By nac at Thu, 2003/07/03 - 5:00am

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?


By Anonymous at Wed, 2003/07/02 - 5:00am

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?


By AC at Wed, 2003/07/02 - 5:00am

Java and C++ are mostly written in C++, and they probably be using system widget libraries such as Qt.


By Bzzz at Wed, 2003/07/02 - 5:00am

But these are no significant markets. Usually a company wants to expand. But C++ is a shrinking market.


By AC at Wed, 2003/07/02 - 5:00am

Where do you get your information from?

C++ will be there forever (I even now some programmers that still write COBOL programs) and its usage will even increase. Especially since the new standard will include a much broader standard library (see e.g. http://www.boost.org or http://www.cuj.com/documents/s=8250/cujcexp2106sutter/). Even Microsoft realized that (see http://www.gotw.ca/microsoft/index.htm).

So don't worry about C++. It's alive and kicking...

Christian


By cloose at Wed, 2003/07/02 - 5:00am

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


By Michael Dean at Wed, 2003/07/02 - 5:00am

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


By AC at Wed, 2003/07/02 - 5:00am

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


By David Johnson at Wed, 2003/07/02 - 5:00am

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?


By AC at Wed, 2003/07/02 - 5:00am

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?


By David Johnson at Thu, 2003/07/03 - 5:00am

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


By AC at Wed, 2003/07/02 - 5:00am

But we have Qt that does all this stuff.


By Bojan at Wed, 2003/07/02 - 5:00am

Pages