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.
Dot Categories:
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.
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.
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.
> Qt is fundamentally an "emulating" toolkit, it does all widgets internally.
Only partially true on WindowsXP and MacOSX.
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.
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.
> 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
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)]
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?
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.
Have a look at http://www.uwyn.com/projects/tinyq/
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.
Yep, good question >>will Qt stay monolithic after 3.x or is a more modular design [...] considered?<<
When can we expect to see QTopia, now based on the Qt 2.x series, move to a more recent version of Qt?
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 [email protected] after a reasonable time?
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
Take a look at http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/kmdcodec.h?rev=...
(KCodecs)
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?
Yes, Very good question.
Id like to see "./configure --build-for-kde" or something like that :P
/kidcat
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
ooops.. Brain-Bummer(TM) on my behalf :-/
/kidcat
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/
Interesting.
I want to know if Trolltech has offered QtAWT to Sun...
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).
When will Qt get support for using QToolBar widgets in any widget other than the QMainWindow?
That was reported as a bug ages ago and IIRC we got back a WONTFIX response.
Rich.
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..
>> 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 ;)
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.
>> 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.
They're using a KToolBar which inherits off a QToolBar.
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 :)
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).
> 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?!)
Well, of course it would break the API/ABI so that WONTFIX is pretty logical.. but perhaps it could be done for Qt4?
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?
Java and C++ are mostly written in C++, and they probably be using system widget libraries such as Qt.
But these are no significant markets. Usually a company wants to expand. But C++ is a shrinking market.
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
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...
But we have Qt that does all this stuff.