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
Dear Trolltch, SWT is realy a great GUI Library for JAVA.
On Linux the GUI-Connection is done with GTK (or x86/Motif)
When will you support IBM with a QT Binding?
Mike
Good question! I would love to see Eclipse using Qt instead of Motif/GTK.
Yeah, me too !!!
Eclipse is simply wonderful, now if it only would support QT ... ;-)
That should be great, but I think it's impossible due to licensing issues. SWT is CPL, while QT/X11 is GPL. I think it's only possible when TT will make something like a SWT exception in their license.
Yummy,
Eclipse on QT/Embedded would be great!!!
yep, i dream of doing java development on my palm pilot quite frequently...
eclipse and qt are opposite ends of the spectrum. eclipse using swt was designed for native widget binding. as i understand, qt emulates it's widget rendering. this would put you back to a netbeans type of application. that emulation requires MUCH MUCH more overhead.
I don't see why Qt is less native than Motif or GTK widget libraries.. SWT do bind to native (as in non-Java implemented) widget libraries and that is what makes it so much faster than Swing.
They haven't implemented an SWT port to Qt yet because of licensing problems. Qt's license (at least used to) conflict with IBM's Common Public License.
According to the IBM guys on the eclipse mailling list they already have the Qt bindings done, It just can't be release because of the licensing issues.
I think they already did an AWT peer implementation for their Qtopia platform.
Cheers,
Kevin
Qt...Powerful.
Eclipse...Powerful.
Qt+Eclipse...Painful.
I found it so hard to work on Eclipse with Qt, maybe I'm a rookie after all.
I'd like to see Eclipse with a Qt or (even better) KDE GUI, too!
BTW: Netbeans is faster on my Linux box than Eclipse, but on Windows Eclipse is a lot faster. Seems that the overhead of GTK+ is bigger than the overhead of Swing.
Now, I'd like to use Eclipse on Linux, but the look of it is just annoying in KDE.
gargamel
Regarding licensing, please, IBM, do listen: GPL rules!
And as long as there is GPL'ed Eclipse version with a Qt or KDE GUI I'll always prefer Netbeans. It's also faster and much more efficient in current versions. And: The Netbeans modules all work, whereas the majority of Eclipse plugins just suck.
gargamel
ever consider selling Qt to Sun or anyone else? Those who work there tell me that many people are tired of Gtk but are now stuck w/it for now.
2) A lot of people and small companies are interested in Qt but are afraid of developing with the free version and cannot afford the licensing for the commercial version. Will Trolltech do something about this situation?
Sun and Macromedia are going to like GTK2 ...
GTK2, especially with c++ and c# wrappers shims and what have you, is really good. And it's still being developped and improved, cleaned and ported to native Win32 and Carbon. The advantage of C is it a flexible mess that can be easily ported and optimized :-( And ObjectiveC is the best of all :-(
Qt's *massive* advantage in documentation is gradually being eroded too ...
what to do??!!
> Sun and Macromedia are going to like GTK2 ...
Uhm..? Macromedia uses gtk? That's news to me
>GTK2, especially with c++ and c# wrappers shims and what have you, is really good
gtkmm, for what it's worth, still very much feels like a wrapper unfortunatly.. I agree it has been cleaned up from it's quite messy gtk 1.x days (and is now finally usable), but it doesn't feel like a nice, complete coherent solution like Qt does.
> And it's still being developped and improved, cleaned and ported to native Win32 and Carbon.
While there is a fork of gtk to use carbon, the main one still uses x11 unfortunatly :(
Last time I saw, gtk still doesn't integrate as well as Qt does on win32 either. It doesn't use WindowsXP Visual Styles, but rather uses gtk-engines :(
> The advantage of C is it a flexible mess that can be easily ported and optimized
true, but it's a myth that C++ can't be as portable. after all, Qt works very nice on both MacOS and Windows, and has for years. gtk might have also, but it still doesn't work well on either one.
> And ObjectiveC is the best of all :-(
I personally gind objective-C quite awkward and less powerful compared to C++. I think a lot of other people do, seeing the relative popularity of C++ compared to obj-C. But hey, if I had learned obj-C before C++, I might feel differently.
> Qt's *massive* advantage in documentation is gradually being eroded too ..
Agreed.. time for qt to use doxygen! (which ironically, uses Qt)
If I was at the head of Trolltech, I would want to see Qt being used everywhere it made sense, pervasively. Do you, Eirik, have the same attitude? If so, what kind of steps do you or would you take to increase the market adoption of Qt?
For example, are you concerned that a distribution such as Red Hat may not install Qt by default? Are you concerned when commercial companies such as MandrakeSoft, IBM, Sun, Macromedia choose GTK+ over Qt? Are you concerned that GTK+ provides functionality such as fully-fledged X11 accessibility that Qt doesn't have? Do you pursue efforts such as the recent CE Linux Forum formed by the industry giants aggressively?
> Are you concerned that GTK+ provides functionality such as fully-fledged X11 accessibility that Qt doesn't have?
Qt supports accessibility for Windows. As accessibility is a condition for selling software to the gouvernment in the USA, how important is it for Qt to have this feature?
And how do you evaluate the efford of the KDEAP to write a bridge to the GNU accessibility framework (at-spi) for your business?
Why is there no GPLed Qt 3 for Windows? The lack of this has stopped a number of my friends from using Qt for their free software projects.
Yep, this question popped up in my brain too...
Please ask this question; I was about to post it myself.
I really want to know this one as well. I would love to use QT for a project that I am planning (free) but I need database access across platforms with grids, etc and thus want it in the GUI toolkit. Even GTK+ doesn't have that, so I will be stuck with either Java or WxWindows without a free QT3 for Windows.
I question this as well. I've got a project intended mainly for a windows audience that I develop on Linux. I've kept it hobbling along by mainting backwards compatibility with Qt 2.x and the Qt Non-Commerical Edition. I'm not necessarily stuck on having a GPL version for windows, but I'd *really* like to see more regular releases of the Non-Commercial Edition. It would also be great to see these releases made with cygwin/gcc compatibility rather than requiring MSVC.
I can understand the concern about maintaining the revenue stream, and that this is low on TrollTech's priority list, but it would be interesting to hear about it. Heck, I'll bet they could find lots of people who'd be willing to sign an NDA and manage/maintain these releases so that it wouldn't be a burden on TrollTech.
Just my $.02.
Ken
My vote here :-)
(disclaimer, i don't run windows, i just wonder if a gpl windoze qt would increase marker share significantly for qt)
This question has already been answered in the past, I think it was in my previous interview. His answer was "When windows becomes Free Software, we will release Qt as free software for windows".
... which basically means "Never." ;)
So when did Mac OSX become Free Software?
MacOSX, as a platform, relies a lot more on free software than Windows does.
Maybe so, although my understanding is that there is also quite a bit of BSD code in Windows. Obviously MacOSX has _more_ BSD inside, since it is based on BSD, but MacOSX is hardly free. I don't have a bone to pick, I was just challenging the reason given for the lack of a GPL'ed Windows Qt. The obvious reason is that Trolltech's bread and butter is the Windows Qt.
My uneducated guess about Trolltech releasing a GPL Qt for MacOSX, is that it signals an increasing level of cooperation between Trolltech and Apple in the future. In fact I wouldn't be surprised if Apple buys Trolltech, given the vast amount of KDE applications and libraries built around Qt. Apple would be tapping into a massive amount of "free" resources for their platform.
Sean.
> Obviously MacOSX has _more_ BSD inside, since it is based on BSD, but MacOSX is hardly free.
That's true, but MacOSX's kernel, Darwin, is completely free. It's directly based on FreeBSD. Not only this, but unlike Microsoft, Apple chose to keep the BSD code within OSX (Darwin), under a BSD license, so public code is available. Microsoft chose to keep their BSD-derived code closed source.
Windows is significantly more closed than OSX as a result.
Of course, I agree that the real reason is that TT's main money comes from Windows.
Maybe he could elaborate on why Windows not being free software prevents Trolltech from releasing Qt/Win as GPL. I don't see the connection at all; I think releasing Qt/Win under the GPL would only benefit Trolltech, free software, and if anything ease migration away from Windows to Linux or Mac OS X.
But Trolltech doesn't (as a company) have any reason to want you to migrate away from Windows. They don't sell migration, the sell a cross platform toolkit. Nor does people migrating to Qt without any motivation to buy a copy help TT. As much as they might like to say, "Wow, isn't that neat? They're using Qt!" it doesn't pay the bills.
Being pragmatic, you have to ask what benefit would it be to TT to release Qt for Windows?
You also have to realize that most of the places Qt is being used are for internal tools -- in these situations companies can quite easily just use the GPL'ed version and simply never do a release. Many companies will of course still want support, but TT seems to still be overwhelmingly a "software" rather than "services" copmpany and as such has to have some mechanism for continuing to sell their software.
If you're developing on Windows, you should be used to paying quite a bit for software -- those compilers don't come cheap...
"Being pragmatic, you have to ask what benefit would it be to TT to release Qt for Windows?"
Freeware using Qt increases Qt visibility. Windows is, by far, the most common desktop platform and even a small number of well-known Qt-based freeware applications would make Qt much more well known, potentially leading to many more sales. Think about KDE for Windows for example -- wouldn't it be an excellent showcase of Qt's power to the many Windows developers out there?
What I mean is that the rationale for a GPL'd Qt/Windows version is the same as for a Qt/X11 one. Why the asymmetry?
"But Trolltech doesn't (as a company) have any reason to want you to migrate away from Windows."
They sell a cross-platform toolkit, so I think a desktop market that is more equally split among the different platforms could help their sales a fair bit, too.
"If you're developing on Windows, you should be used to paying quite a bit for software -- those compilers don't come cheap..."
Not true. gcc with mingw32 and Borland C++ 5.5 are both perfectly good gratis Windows compilers.
I guess most people on Windows, including developers, don't care about things like toolkits. It's just a no-issue over there, because software on Windows just works (or if it doesn't it's not because of the tookit). With a good toolkit the app looks and behaves like a native Win32/MFC app. And if a Windows developer wants a better, higher level programming development, .NET is a logical choice. Qt is very exotic for a Win32 dev.
"Paying Quite a bit for windows compilors"
Not likely! Ofcourse theres that dev c++ but for me...nothing less then vs.net pro 2003..and no i didnt pay...my school has a msdn license and we get all these amazingly expensive developing apps and windows xp pro and other versions, media edition if we want, for free...and msdn help thing...and when whidbey comes out we get that to! and longHORN!! ALL FREE!
now your comment is wrong in that you think because people use windows, they actually spend money on software...which is laughable in every way...*well you know what laughter sounds like :D*
I've seen no recent activities in the QT# area.
Does Trolltech consider the .Net platform as a future target for QT?
As many people are ask when KDE 4.0 will be released, this question would be interesting :)
When do you expect to be releasing QT 4.0 and what features do you think should be there by then?
Yes, we want to know!
Especially >>what features do you think should be there by then?<<
Does it annoy you when people spell Qt as 'QT' instead of 'Qt'?
I don't think they care much about it, but it seems you do ;-) QT, QT, QT :D
I'm a programmer, I can't help it. It kills me.
I'm a programmer too (better said, I do program), ... but I can't see the problem. There's nothing in between most their classes that says "Qt". It's only "Q" that turns up usually (QWidget, QString, Q...).
As you can see above I make the mistake sometimes even myself. But that's mainly due to the spellings of GTK, KDE, ... and one ends up capitalizing everything. Anyway, have you noticed that their logo has actually a capital lletter "T"? ;-)
Do you use Unix? Cuz everything is case sensitive there, just like it usually is in programming.
The problem is also that Qt and QT are not the same thing. One is a GUI toolkit, the other one is also known as Apple's QuickTime. And have _you_ noticed that they used to be called TrollTech and now they are called Trolltech? Just goes to show that capitalization matters. :-)
Actually, "Qt" prefix is used for compatibility classes, those
that were removed in some release, but are kept in the attic/
directory of Qt sources to help port apps (i.e. by adding them
to app sources). For example, Qt2's QTableView, which was removed
in Qt3 became available as a QtTableView standalone replacement class.
If you watch the videos on the site you can hear that the original (marketing) name is QT, while the developers call it 'cute'.
I spoke with a windows developer recently who is using MFC to build his applications. I was trying to get him to evaulate Qt, because this would obviously make porting his apps much easier. He did, and didn't like it, for the following reasons:
- Qt isn't "native" MS Windows, meaning if you install extension plug-ins that eg. let you enter japanese text into widgets, or extend functionality (eg. password databases that automatically fill out login dialogs etc.) these plug-ins will only find widgets developed with the MFC libraries. MFC apps just "play nicer" with the rest of the system, he claims.
- There are "lots and lots of MFC extensions" available for just about everything if you don't want to roll your own. Need a connection to a specific database or a table widget with special properties? Chances are that you can license it for ?200 instead of spending a week rolling your own.
Now I don't claim these claims are right (are they?), but if they are, are you considering to change this? If so, how?
This, and the fact that you still need to license MS Visual C++ to be able to use Qt seems to be a major problem when trying to convert professional developers.
I don't think there's much they can do about that. Qt is fundamentally an "emulating" toolkit, it does all widgets internally. That means less OS integration than you'd otherwise have because it's not a first tier toolkit (except on Linux, where sometimes it is).
Changing Qt to use native widgets would probably mean mostly rewriting it. Abstraction toolkits often have looser semantics as well, so basically I doubt they'll do that.
OTOH MFC isn't so great really, so like most things you have to balance the pros and cons.
so then, fundamentally, it's similar to Swing from the java camp? i've done limited KDE/Qt development circa kde 2.2, and it was nice to code for. the trouble is, machines aren't really that powerfull and memory still isn't that cheep for using a emulating toolkit as a desktop (consider a swing desktop?). netbeans and eclipse are prime examples of using an emulator .vs. native widgets. eclipse wins hands over foot. course, that's at the slight expense of minor appearance difference and such on different platforms.
i commonly use a kde 3.x desktop outside of work and find it ice to use, i just wanted to pipe in on the emulator .vs. native topic. i prefer native when available.
Yes, more or less. I guess it depends on the platform, on MacOS it seems to use their style API.
The same for WinXP. And for KDE, of course, the Qt style API is
the native API.