Interview: Trolltech's Eirik Eng and Matthias Ettrich

Eirik Eng, president of Trolltech, and Matthias Ettrich, founder of the KDE project
and director of software development at Trolltech, were interviewed by Philippe Fremy, KDE enthusiast.
This interview was conducted in August 2003. The interview was made
possible by Laurent Rathle, who is maintaining the KDE France
website. A French translation is available on KDE-France.

Before entering the interview itself, I would like to thank heartily all the
people who have given their time to transcript the 90 minutes of interview
into text and edit the result: Dave Brondsema, Navindra Umanee, Nicolas Verite, Stephan Binner, Laurent Rathle,
Pascal Audoux, Sylvain, Fabrice Mous and Ingo Klöcker.

An important note to all the readers, Qt is pronounced 'Cute' by its

Philippe Fremy: I don't know if you remember, but this is not the first interview
I have done with Trolltech. I did one by email two years ago.

Eirik Eng: I remember that. Quite a lot has happened in two years.

PF: I guess you know that I have been asking around the community for
questions to ask Trolltech.

EE: Yes, we saw the article on dot.kde.org, that was a good idea.

PF: What is the state of your business today: How many licenses are
you selling, what are the main sources of profit, the type of clients?

EE: Today, Trolltech has 76 employees. We have one office here in Oslo
where we are around 50 employees, we have one embedded office
department in Australia (in Brisbane) and we have sales and marketing
offices in the United States, each with about 12 employees.

Financially, Trolltech is now about break-even, capital-wise. We had a
period of two years where we were losing money. Specifically due to
growing the organization by using the investments that were received
in 2000. Right now, we are at the point of break-even, but we see
that our income is growing faster than our expenses. So things are
looking very good for the future.

In terms of customers and licenses, we now have well over 2000
customers and a typical Trolltech Qt customer is either a large
company that has its own software development department or a small
company that specializes in software development. That's the two
typical types of customers we have today.

We have about 80% coming from the desktop business and development
tool business, and 20% coming from Qtopia and Qt/Embedded.

PF: In which countries has Qt had more success or less success?

EE: In terms of sales, we have about half of our license sales in the
USA and a clear second is Germany, with about 20%. France and United
Kingdom are competing for third place with 5%. I think Japan is
getting pretty close to France and UK.

We have sold to 65 countries so far. It is really a very distributed
market and everything is over the net, of course.

PF: Now, a question that everybody has been asking: Why isn't there a
GPL version of Qt3 for Windows?

EE (laughing): As some people mentioned on the dot, it has partly to
do with finances, sales and Trolltech's business model. Another point
is the fact that Windows is a closed source Operating System. There is
no community for Free Software development under Windows. The
situation is very different from Linux, as you know. On Windows
development usually happens as shareware or commercial software and we
don't see that community evolving into producing Free Software.

PF: So basically, you think you would not leverage a similar effect as
you did with Qt on Linux?

EE: Not at all. And we have considered the risks for us as a
company. Still today, a big part of the contacts we have with
customers are the people registering for the evaluation version for
Windows. They have to give us a name, an email address and tell us a
little bit about their project. Then we give them an evaluation
version for Windows. This is how we get in contact with the customers,
how we can find out information about their project or what they need
and help them understand the licensing model. So, that's part of what
we risk losing.

As you know we are doing an experiment these days with the Macintosh
port. We have seen that there is a very good evolution in the
Macintosh community. There is a lot of Free Software development going
on and we thought this was the right time to GPL the Mac OS version,
to make sure that the Free Software community for Mac OS X has a great

PF: About Qt on Mac OS, the very first announcement on the website mentioned
Qt running on Mac OS 9. It was quickly removed, something like one day after.
Did Qt really run on Mac OS 9 or is it just limited to Mac OS X?

Matthias Ettrich: We had a prototype on Mac OS 9 and some applications were running, but it
was far from production quality. And we figured out that there were many
limitations in order to complete our work. Mac OS 9 had too many limitations.
At that time, Apple was clearly saying that they were moving to X, that 9 was
going to fade out. That's why we started a totally new port, to Mac OS X.

PF: Eugenia Loli-Queru (from OSNews) has been complaining in an
article than on Mac OS, Qt applications are not perfectly like the
Aqua applications. The complaint is that Qt is actually emulating the
first version of the Aqua style, and Apple has since then slightly
changed the style. So you are not using native Mac OS X API, unlike
the Windows XP version of Qt. Is that correct?

EE: Yes and No. The very first version of Qt for Macintosh, the 3.1
version was emulating the style. It was the first Aqua style and it
has changed a bit.

The current version (3.2), and the one in GPL, is actually using
Apple's style API to draw widgets. That means that we follow whatever
changes Apple does to the style and that Qt stays up-to-date.

So there is no reason to complain about that anymore.

PF: Have you had any commercial relationship with Apple when you were
working on Mac OS? Do you plan any future partnership?

EE: We don't have a formal commercial arrangement as such but we have
very good contacts with Apple and we speak to them regularly, on
several levels. They think this is a very good thing. For the time
being we decided to cooperate just informally, like what we are
doing. We are getting a lot of support in return, most notably at the
Worldwide Developer Conference. Central people at Apple have been
presenting and talking about Qt as a very good development solution
for the Macintosh.

PF: Right now Qt supports accessibility on Windows and you probably know
that in the US there is a law which states that if want to sell software to
the government you have to enable accessibility in your applications. What is
Trolltech going to do about this?

As you know GNOME has a very strong support for accessibility thanks
to the work of Sun, Gtk+ provides simple bindings to accessibility
devices. Qt in this regard is quite behind. And there is work going in
KDE in this field too. So I would like to know what do you plan to

EE: We're working on it, there has been a lot of things going on in Qt
development lately. This is something we are actively working on.

I spoke with the developer who has started working on the
accessibility module of Qt. This is definitely something that is
needed, but it has not been on the top of the list for many of our
customers. This is why it took us so long to start this project.

ME: There some problems when doing accessibility on Linux right now.
First of all, the market is not yet demanding. I mean, there is no
customer saying "This is something that we absolutely require right
now". Another problem is the work done by Sun: the ATK on Linux. The
trouble is that an accessibility framework for a toolkit is not useful
if you don't have the integration and a tool to actually test the
development. This is a bit of the chicken and egg problem. It doesn't
make sense to develop applications if you don't have the controlling
tool to actually use these things.

In order to implement accessibility in a toolkit you need another
middleware infrastructure that can bind that in. That means
accessibility require that your applications can actually talk to each
other. You need an IPC system. This is all built into windows but a
standard is lacking on Linux.

So the first thing that we need to have is an IPC protocol. I think
GNOME is using CORBA for that, so we would have to integrate that
first before we could use the accessibility protocol. It's not that
easy, it's an infrastructure, you can't just sit down with a developer
for a couple of weeks and then you have it. It is actually much more

But there is work going on in the KDE community and I hope that we in
Trolltech will be able to provide resources in the near future to
solve this problem. Because it is not enough if we [Trolltech] do
something, it's important that the Free Software applications support
it too.

PF: You said that the business is not ready to receive it, that there is no
business demand. Maybe if you start to propose, the business will move toward
accessibility. Then you could be proposing instead of just waiting for people
to ask.

ME: Sure, but this is a game, this is an investment. Trolltech is, like Eirik
told you before, cash-flow positive. The investment can push developments. If
we had had enough resources, I would have worked on that five years ago.

PF: What do you think of the Opie project and its relationship with Qtopia.
Is it a competitor? Are you thinking about reintegrating some advances of
Opie back into Qtopia?

EE: We think it's a very good thing that there is Free Software project now,
working on PIM application suite. We have very good contact with the group.
From what I understand, we already have integrated patches from the Opie
project into Qtopia. We are working together with them to make sure that we
have binary compatibility on the infrastructure.

It is again limited how much a company can do. This where the Open Source
model is excellent, as long as there are enthusiasts out there, willing to
work on it and making it better.

We don't see competition since this is a Free Software project using Free
Software licenses. Our business model is based on cooperating with Free
Software projects, making sure that people who use our software for Free
Software can use is for free. Our customers, however want commercial licenses.
They pay it for development and for the support. We think that this is a very
good model and it is working very well.

PF: Qtopia is based on Qt 2. Is it expected to move Qt 3? And if it does move
will you keep the binary compatibility so that legacy applications can still

EE: Complicated question.

Of course one possibility, that Matthias is mentioning to me here, is isolation
of two libraries for a true binary compatibility in the future. So it is
possible, but it is not a very good solution because it uses a lot of memory.

One of the historical reason to keep Qt 2 for Qtopia is that many of our
customers are very focused on stability and as you mentioned binary

Qtopia will more than probably integrate into the current version of Qt in
the future. But we have to do it in a sort of one big
step for our customers. It would probably be provided as a binary
compatibility option as Matthias mentioned. But our main focus is on keeping
most of the source compatibility, so there we will be more or less a simple
recompile to make these applications work on all platforms. I think it has to
be one big chunk of operation, when we move to new level and break the binary

PF: Some people complained that some parts of Qtopia are not available
under a free license, for example, the desktop. It doesn't really make any
sense, why not release the desktop under a free license so we can use it,
even on more platforms like Mac OS?

EE: It has to do with historical reasons and it has also has to do with the
business-model. We do that to make sure that there is one component there that
customers need and so they come in contact with us. There are other parts of
Qtopia that are not completely free, for example: parts of the e-mail reader as
far as I remember. It is always a fine balance for Trolltech and I think in
this case it turns out to be a good solution. But I do see the problem there
with the Qtopia-desktop.

PF: Was Zaurus a success? Did it sell well? Do you think there is there really
a future with Linux on the PDA?

EE: Yes, I think definitely there is a big future for Linux on the PDA? Did
it sell well? We are not allowed to go out with Sharp's numbers
unfortunately. I think it is selling well in some markets. It was a very good
first-time project. It was the first large conceiver brand that embraced Linux
in this way and I think we are going to see Sharp coming up with new
generations, which are going to become better and better. I know that
in the enterprise market they are doing very well. So in general: Yes, it has
been a success. It has been a very very important direction for Trolltech, for
the Qtopia-product and make Qtopia known in a lot more circles.

PF: Recently there was an announce about a big electronic consortium being
formed to use Linux on embedded equipments. Does Trolltech have plans
to contact them and do something with them?

EE: We are in contact with them right now to see how we can cooperate. We
think it is very exciting that so many large companies are backing Linux on
portable devices this way.

PF: There are many many free software projects trying to use Qt in different
languages with Python, Ruby, Java, C#, Ada. Some bindings are missing, some
are half-done, some are done very professionally. Are you supporting this kind
of development? I mean, are you just watching them or sometimes would you be
interested in supporting the people doing this in order to have a wider
possibility for the usage of Qt?

ME: We have had contacts with some of the authors of bindings, so we support
them on request and have contact and talk to them. We keep that option open to
do more things with bindings in the future. Our current stand is that there is
very little commercial interest in those bindings. There are also surprisingly
little Free Software using them. There are very few applications being written
with those bindings.

Qt as API shines most with C++. Together with C++ the overall value of Qt is
much bigger than when you do, for example, use Python-bindings. One of the
reasons for that is that Python - but you could pick Perl or any other
language - have a large set of libraries and additional tools.

Python has stuff to do network, server programming, to do I/O, XML. If you put
Qt on top of that, you are only interested in the GUI, whereas the C++ people
will use the XML API, the file abstraction and all the things so the value is
much higher.

PF: The PyQt/BlackAdder license is so cheap in comparison with the full Qt
license. How can you make money out of this ?

EE: It is a very limited market as Matthias has mentioned. And it is also seen
as a commercial experiment to see how much interest there is in it. And we
have been marketing together with TheKompany on it. The question is good
and so far, at least from our side, it has been disappointing how few
companies actually have an interest in developing using such a tool . I guess
that comes back to, as Matthias said, Qt is really a C++ toolkit and that's
where it shines and really add value.

PF: If you look back at everything you have achieved with Trolltech, what
would you like to underline, what are the things you are proud of, or the
things you really regret that happened, the mistakes you made?

EE: First one is really easy to answer, what's makes me personally most proud
is the fact that we have made life a lot easier for a lot of people who are
developers out there. When I started looking at multi-platform GUI toolkit
together with Harvard back in 1990, we saw that the API was terrible and that
they were so difficult to use. You had to spend a lot of time reading the
documentation to find how to use the tools, and we decided that it could be a
lot better. You could make an API that really is logical and
easy to use and you could make the application developers concentrate on the
creative part of the work and actually making their application logic, not
using the toolkit. In many ways, we have achieved that. I still get a thrill
out of the feedback customers saying "Wow, this is fantastic, you've really
given my the fun back in doing the job". And that's what I am the most proud
of. I mean, commercialize the toolkit that makes daily works of programmers
much better.

PF: And on the things you regret and wish did not happened?

EE (laughing): That's easy to answer too. I let Matthias answer.

ME: It's an open secret that the full opening of Qt came to late. We
should have done that earlier.

At the time where we were doing the first free version of Qt, there were
people saying that GPL means you can do everything with it. So people don't
know much about free software licenses in the market. So I don't know what
would have happened. I don't know what would have happened if we had GPL Qt in
1995. Maybe Trolltech would not exist today. You never know. But I
personally do regret that we could not do it earlier.

EE: Yeah, I agree. But also, part of the discussion at the time was that if
you go there, you can possibly come back on the decision. We saw that once we
were going GPL, there were no going back. There was a lot of internal
discussions about the risks. For example, a company could start
a fork, for example Red Hat, and we would lose control about what was the only
bread and butter of the company. But as Matthias said, once we did it, it was
amazing to see the effect that we got so much positive PR, and good will in
the community. In practice, nothing changed. We still have the control,
people respected that Trolltech had the latest official version and things
continued as they were previously. It was the right choice but, yes, we could
have done it earlier.

PF: Do you plan to extend your business in the future to something other than
strictly selling a library? How about selling books, packaged software,
trainings ?

EE: We are already selling solutions to hardware developers of portable
devices: Qtopia. This is actually quite a different type of business,
although technically it's the same basis.

We also do sell training classes, although we outsource most of the
practicality of it. But as a company, right now we are trying to focus on
things we're good at. Who knows what's going to happen in the future? We have
so many exciting possibilities within the basis we are operating in already,
development tools and platforms for mobile devices.
We almost have the opposite problem internally. We have to choose the best
options going forward and not spread too much into too many things. It's
really important to focus on our core knowledge.

PF: Do you plan one day to make Qt Designer a full IDE? Do you plan to
separate it into different modules so it could be integrated separately in
other projects, like KDevelop or Kommander ?

To question one: no, but one should never say never.

The second question is a much more likely option and yes we do have concrete
plans. I can not promise a release date however. KDevelop has developed into an
excellent IDE. I think it's really amazing what the guys have achieved. This
thing is in many ways the period to what you get today on Microsoft Windows
from Visual Studio. What the problem is with KDevelop right now is that the
GUI builder, which is Qt Designer is not available
as an integrated plugin. Today we can not offer that because the way Qt
Designer is written makes it very hard to take the form editor out and
integrate that into an external tool like KDevelop. We will work on making
this either possible through plugins or through libraries. That will take many
more months before that is finished. But this is one of the goals we have to
cooperate with the KDevelop team.

PF: As you know probably, IBM has released Eclipse and the SWT, an IDE and a
GUI toolkit for Java built (unlike Swing) upon native toolkits. It currently
uses Gtk+. Is it planned to provide it for Qt? There is a license
incompatibility, which is hard to deal with but achieving that would be very

EE: We are in contact with IBM and have been for some time over this. And as
you mentioned, it's basically a licensing issue. Our business model is based
on the fact that developers who want to use Qt to make closed source software,
have to purchase the license from Trolltech. It is very important for
us to maintain that model; that's how we survive as a company. And we're
having problems finding a licensing solution for Eclipse to make this possible
for us in the future. So we're still talking to them, but it's difficult for
me to see how we can find a licensing solution, unfortunately. But I agree
with you, it would be great if we could make this happen.

PF: Have you encounter any competition with Gtk, in the commercial software
field. Are you aware of a situation where you have lost customers to Gtk or
people just told you "we prefer Gtk and won't use Qt at all"?

EE: The short answer is no.

PF: And in the opposite case?

ME:I think that even if you don't believe it, it is true, actually true.

EE: Basically, the company we are in contact with, want a C++ solution,
because Qt is only available on C++ . If you make a comparison between Gtk+
and Qt, for C++, Qt wins every time. We haven't seen any company that chose
Gtk+ over Qt. When we are talking about C as a it's a different story, because
you have the opportunity to use Gtk with C and you cannot use Qt with C. I
would suspect that a society looking for a C solution would probably would go
with Gtk, but I've never heard about them.

PF: You were talking about Red Hat and you were afraid about Red Hat forking Qt
and making business of it.

EE: In fact, in stone ages, that' right.

PF: Have you been in competition with them regarding GUI development: they
have a strong position in Linux and they are pushing GTK. Have you been facing
them commercially in this area?

EE: No, actually we have not. Not, that I know.

PF: And have you tried to approach them and try to convert them to Qt instead
of GTK ?

EE: Not really. We have been in contact with them several times through the
fact they have chosen GTK for a lot of their projects. Again for C++ Qt is
superior and I believe for any C++ project out there people would choose Qt.
In the end, no, we're actually working on it.

PF: What do you do to make Qt adopted everywhere?
Are you active about talking to companies that are already using GTK and
converting them to Qt? For example MandrakeSoft that is using GTK for all
his configuration tools, Macromedia for his RealPlayer, no it's not
RealPlayer, Acrobat Reader which is using Motif, and things like that...

EE: From time to time we are in contact with those companies explaining them
the advantages of QT but I think we bumped into licenses issue or language
issue. We're working in this base.

PF: Are you aware of companies that are writing really new consumer products
converting their currents ones to Qt, except for the one you have been
advertising on your website?

EE: Nothing we can talk about right now. Most of our customers would like to
keep their project secret until they're ready with the final version. So,
they're nothing that we can talk about right now.

PF: I read a few articles on the net, saying that basically all the movies
visual effects companies are moving onto Linux. You are advertising one on
your website, which is moving to Qt. Have you seen big move to Qt in this area

EE: Yes, we are seeing a big move in this area. And it is basically to move
on some customers in this base. Others have been interested because of
that. We are seeing a lot of those companies moving to Qt right

Actually, the market where we see most movement right now is this one
and next is EDA (Electronic Design Automation) software tools that layout chip
design. We see a lot of companies that are also moving to Qt.

PF: So that's very specialized high market. For very dedicated and very
expensive tool.

EE: yes

PF: Regarding the availability of Qt 3 for Windows, have you think of a
solution to the problem that people cannot build free software on windows with
Qt. They really regret that. Would it be possible to have something like a way
to submit a project to Trolltech and receive the project back built on windows
so that they wouldn't break the license. They wouldn't use a free version of
Qt but they would be able to provide their software on windows.

ME: The problem is not so much our licensing, we wouldn't have a problem with
that at Trolltech but the problem is typically the Free Software licenses.
You cannot take a GPL Linux program, compile them with Qt for windows and
give the executable to somebody else, because you would violate the GPL.
[Ed: because Qt on windows is closed source]

So this is the biggest concern. We could even do a non-commercial
version for windows like we did with version 2 but the trouble is that,
because Qt is GPL you cannot use this version to port Free Software to
windows, so the only option they really have is likewise, that would be a GPL
windows version and Eirik talked about that earlier.

PF: It's just about putting an exception in the license of the software, I
think many people would be ready to do that to use Qt. Right now what stops
them is the price of Qt for Windows. I was talking at the manner they are not
getting the license but still be able to distribute free software on windows.

ME: It didn't happen but we have released the non commercial version for
windows. Most free software projects, once they are out, get so many
contributors, all under Gnu GPL, so you can not really add such an exception,
later. Also, I don't forget that they're is an option and an option to use of
the Cygwin and use the X11 for windows version GPL X11 version of Qt.

PF: Yes, but it's a heavy work for the one that are running the software, they
have to run the X11 windows system with Cygwin. It won't work with small

ME: Short answer: as a Free Software and KDE guy, yes, this is really
unfortunate but there is nothing we can do about this.

PF: How are people reacting to QSA, the Qt Script for Applications ? Have you already have a commercial reaction about it?

EE: It has not been out there for that long but several customers needed that
thing and it looks very positive so far. We sold several licenses.

This is very early in the process. Typically for a development tool like Qt and
QSA, commercial customers need one to three month to really get into the
product, evaluate it and see how they can use it. In few month we will see
more clearly how it succeeds in the market.

PF: Would you see QSA using other scripting languages, like for example python

ME: QSA is the JavaScript. We could build a scripting solution,
with other scripting languages, the binding technology is not tied to the
language at all. This is possible. It depends on whether we see the commercial
interest. The point is JavaScript/ECMAScript is very small language. If you
ship an application and you make this application and this languages very easy
to document and you can give that to your customers. If you bind python, your
clients get this huge programming framework with all the additional tools.

I mean that QSA embedded makes your application scriptable, it is not a competitor to python and PyQt at all, this is not the point. To be technically
clear, when you make your application scriptable in QSA, you do not have the
entire Qt API accessible on script. You just write Qt code with your scripts
but you have access to functionalities of your application, this is what people
do with it.

PF: And was it possible to use the KDE JavaScript that have been developed
for Konqueror?

ME: QSA is an extended version of the KJS engine.

PF: Is it really based on the same code ? Or it is just a rewrite.

ME: It is based on the same code and it was written by the same person, Harri
Porten, who wrote the KJS engine, put it under a license that explicitly
allowed to incorporate into other products.

And he was doing that work for Trolltech. The difference is that KJS is aiming
for web browser, it means it support an older version of
ECMAScript/JavaScript, with a lot of compatibility things. In QSA, we
took a lot of those compatibilities out and followed the clean ECMA standard.
This is also a modern version of the language that has object orientation and
classes, that you do not have on the web JavaScript today.

PF: There was a real demand for the JavaScript language or you just
choose this one because you find it simple?

EE: ECMAScript or JavaScript looks like a very strong pretender to be a
standard embedded scripting language. We believe it is a very popular language
and has been used in many places. Python and Perl are much more used as a
stand-alone programming language. For example, Flash, is also used in
ECMAScript, that's many more things like that.

PF: One question about team builder [a Trolltech tool to distribute
compilations on multiple workstations] : is it successful ? I know there is an
equivalent program running on Linux that does the same thing.

ME: It is not doing the same thing.

PF: And, is it selling well?

ME: It's selling better than what we invested in it, so in this way, it is a
success. It is not a big part of profit income but it is a small extra product
and because of the income we get from it, we can actually invest on it and
improve it.

EE: It's a good product for larger customers having site licenses. They are
normally interested. They have a large development group and lots of
machines on the network.

PF: And to you plan to make it support the windows compiler too?

ME: Yes we do. It is not that simple because of the Microsoft compiler. It is
much easier if you use GCC on windows. But the Microsoft compiler, the
Microsoft "make" does not support parallel builds, so there is no option like
"-j and here we go". This does not work. There are other ways in order to
parallelise the build, that people could use but they are much more difficult.

PF: That's why you haven't released it initially ? That would really be a new

ME: You know windows compiler pre-compiles header files and this is something
that does not really work if you distribute your build system. But the
difference is, that if you use the Borland compiler on windows, it compiles
like 10 to 15 times faster than GCC. So you don't really need teambuilder.

PF: Qt is becoming really fat with GUI stuff, Qt template libraries, XML,
databases. Are you thinking about splitting it into different parts?

ME: Yes, but it can be done in a binary compatible fashion, that means it can
not happened before the next binary incompatible version, Qt 4.

PF: Which is... when do you plan the next binary incompatible version?

EE: It is always difficult to say, there are discussions going on internally
right now. We are working on the infrastructure for the next major release of
Qt, this going to be 3.4 or 4, or whatever, we don't know.

I think that we have a very good creative development model and we try not to
impose deadlines onto our developers.

ME: I would not hold my breath to wait for this version. We are having some
plans. Qt 3 has been out there for a long time. Right now, we could say that
wouldn't be within the next year, we'll have such a new version.

PF: Somebody mentioned that you have some specific prices for startup
companies. Is that true?

EE: We try to be very flexible when start-up companies contact us for
purchasing Qt. Sometimes we give early companies a delay in their payment,
but this is done on a case by case basis, by our sales people.

In general, we want of course companies to purchase in the normal manner from
us. We think Qt has a such a very high value to ease and speed development,
not to mention the multi-platform capabilities that it's well worth it. I
think most companies with a good business model can afford the license prices
of Qt.

ME: On Windows, most small companies buy a windows license, an Microsoft
Office license and Visual Studio license. If they use OpenOffice and GCC, they
can easily afford the Qt license.

PF: How much of a nightmare is it to maintain Qt for so many systems platform
what are the main difficulties? What are the easiest to maintain platform?

ME: The easiest platform are always the platforms that you use mainly
yourself, where you write the code. I mean the various version of GNU/Linux
are not a problem with X11 because that is what we use. Also, the latest
versions of windows is typically a platform where there is no problem.

What is problem is the older versions. Unix has been around for ten
years. They still sometimes quite support the POSIX API, they have
old AIX servers, none of the new AIX extensions is available. So on HP and
AIX, we sometimes have big problems.

On the other hand, on the windows platform we still support Windows 95 and 98
and it requires a lot of work as well.

PF: Are you still maintaining the three versions: Qt1, Qt2 and Qt3, all of
them at the same time on all platforms?

EE: No, we maintain version 2 on embedded platforms and we maintain version 3
but in version 3 we maintain 3.0, 3.1 and the next version, that would be 3.2

PF: Have you ever thought of integrating something like curses and providing
the possibility of using a text-based backend for Qt.

EE (laughing): Maybe for Qt 64? No, we did not thought about this. We don't
see any market there. That would probably be a fun experiment, just as
a weekend vacation hack thing and we welcome people to try. But we don't
see a big commercial interest in such a product today.

PF: Why do you keep your documentation tool secret? And why don't you switch
to Doxygen?

ME: You know the history of Doxygen?

Trolltech in 1995/1997 used the internal documentation tool to generate the
documentation. Trolltech did not release the documentation tool because it was
one big hacky Perl script and it did do exactly what it did, which was
creating the Qt documentation so it wasn't really flexible enough to deploy in
an application. When we released the free version there was a need for a
documentation tool that followed Qt-style documentation. And that was
Doxygen. Somebody wrote a C++ version with Qt to generate the Qt
documentation and application documentation. That is Doxygen. Doxygen
evolved very well, so in application code Doxygen is absolutely a good
choice. We still use our internal tool because we want to be able to
change something easily, like going ahead. When we introduced
properties we had to document them and we changed our documentation tool.
It also happened to integrate walk-through and tutorials. We see
documentation as a big and important integral part of our product. And this is
why we would like to have control, but our documentation tool is not general
purpose enough that we could productify it. So we recommend people and our
customers to use Doxygen.

PF: But don't you think that by making totally open you could have
had some improvements because instead of writing Doxygen someone could
have worked on your own tool, and you could had leveraging the free software

ME: Nobody could have worked on it except ourselves !

PF: Okay, I see. Hacky Perl scripts...

PF: Okay. I wanted to congratulate you for your excellent advertising in
commercial magazines with the Qt ads.

ME: So you like that.

PF: Yes, we found that very funny and it is exactly like we feel with Qt, the
"unfair" advantage. I have been displaying them all at my workplace, for my

PF: You probably know that XFree86 had
internal problems recently, with Keith Packard mainly complaining that
XFree wasn't moving much, that the core developers were not
open enough to allow public access to the core. Do you have
any opinion on this matter?

And secondly, I what is your opinion about how XFree fits with Qt development
? With all your experiences with the various graphical systems on other
platforms, where do you think it should really be improved and what is ready
good in XFree.

ME: That was many questions.

PF: There's a technical question and a political question.

ME: Okay, first the political one. We won't comment on the fate of
XFree86 development, but what we will comment on is that, of course,
we like to see new things in XFree86 and we appreciate that the
development there was done in order to get anti-aliased fonts, in order
to get alpha blending and render improvement. We think this is great
development. Personally I hope there won't be a big split in the
XFree86 community but both parties can work together well. And
regardless what happens, I mean any significant X server or X
server extension that has a significant distribution and really adds
value is something that Trolltech will support. So we really see us in
a position where we use and support XFree86 whatever they come up with.

PF: Yes. Now, regarding the technical qualities of XFree86?

ME: Yes, XFree is quite old. And it's surprisingly how much
you still can do with it because you can extend the protocol with
extensions and they were very smart to architect it this way. So
we actually get very far. There are also many things we would wish X
would do but that wouldn't be X anymore. One example that really annoys us is
that everything is still 16 bit. Now, a window and all the drawing and all
related is implemented in 16 bit. I mean, you can't display a long web page or
long document without doing really hacks because of the 16 bit limitations. I
think having something like that in 2003 feels a little bit odd.

On the other hand the server is everywhere and it's very well distributed and
they did an excellent job. It's a great achievement, a piece of great

PF: Do you plan to move to direct frame buffer support in the future?

ME: We have Qt/Embedded that works extensively on the frame buffer. Is
that what you mean?

PF: Yes, but this is Qt/Embedded. Do you plan to provide this thing for the
main Qt version? Or is it actually the same thing? I'm not technically
familiar with this.

EE: I think that Matthias said that with the current distribution of the X
window system, a Qt frame buffer version doesn't make sense at all. The X
window system is a standard on Linux today on the desktop. We follow the
markets and the standards.

ME: I saw on the dot that some people keep repeating that X is so
horribly bloated and needs to be replaced on the desktop. We do not share this
opinion. X is an excellent system on the desktop computer. Today's
desktops' computers have enough memory, X is not really the problem.
I am using the X remote features fairly extensively.

PF: Somebody mentioned that the Canopy Group & SCO owns some parts of

ME: Sorry, we don't have any influence on them.

PF: Do they have any influence on you?

ME: Not really. They have a 5.7% stake in Trolltech. Historically Canopy
became an investor because we cooperated with Caldera. As you might know we
made and delivered the graphic install, which was the first graphical install
for Linux, for Caldera Linux. The Canopy Group as the main investor in
Caldera was so impressed by the work we had done that they wanted to invest in
Trolltech, to make sure that Trolltech could become a solid company that could
continue to deliver software to the Linux community. It's pretty ironic to
see what has happened historically after that of course. But they don't
have any influence on Trolltech. Trolltech is employee-owned, 65% of the
shares are owned by the employees and we control the business so they have a
small stake in us and that is it.

PF: You haven't talk about this complicated with SCO on Linux

EE: The patent issue or the corporate issue?

PF: The thing that SCO is asking and preparing to sue everybody about some
code they pretend they own in Linux.

EE: I can tell you that we do not support these actions from SCO. Trolltech in
many ways is dependent on the success of Linux. We think Linux is a Good
Thing. We support Linux in many ways. On the other hand everybody has
the right to bring his case to court. In this case it is very strange that
they have not pinpointed exactly where in the code there is a problem and we
feel that if they really had a problem with this, they could have acted very
differently in presenting this to the community. So again we do not support
these actions.

PF: You have any position on software patents? Especially since in the EU
there is going to be a law to be passed soon.

EE: Trolltech is against software patenting. We think it is a bad thing and we
see with horror what is happening to the US software market because of the
patent policy over there. From my limited understanding of the subject, US
patent law isn't that bad, it's the actual application of that law by the US
patent office which is the problem. We sincerely hope that we will not get a
parallel situation in Europe and we think that would be a catastrophe to the
software industry in Europe. We think that we are well protected by copyright
laws and other laws. we think that software is a very different product
from other types of commercial production products. And we think that it
is very important for innovation that people can continue to share ideas and
that companies are not allowed to patent things which are very obvious.

PF: Thank you, I think I'm all done with all my questions. It was quite a long
interview. Anything you would like to add in this conclusion?

EE: I think we went through a lot of things. It was a very good idea of you to
ask the Dot for questions from people.

EE: Thank you for your time.


About the comments about QT beeing better for C++ development this is not (of course) what the GTKmm people think:


Then again, I am a C coder so QT is quite irrelevant for me but if I'm going to start working on C++ I would rather user GTKmm as it is more standard and seems to use C++ in a more modern way.


By Anonymous Lurker at Wed, 2004/04/14 - 5:00am

Bah, get a better trolling line. This one sucks... GTKMM isn't a bad toolkit but it doesn't compare to Qt in scope or maturity. Just compare the APIs to see what the two offer. Qt is a very pragmatic toolkit -- its goals are ease of use, portability and whatnot. If you're really prefer some sort of esoteric sense of "standard" and put that above pragmatism, well, have fun -- but then you probably wouldn't be using C++ either. ;-)

By Scott Wheeler at Wed, 2004/04/14 - 5:00am

The Gtkmm rants against Qt always comes back to the same equation:
- GTKmm is more standard == GTKmm uses templates instead of moc preprocessor to handle signal and slots
- GTKmm uses C++ in a more modern way == GTKmm uses templates instead of moc preprocessor to handle signal and slots
- GTKmm is typesafe == GTKmm uses templates instead of moc preprocessor to handle signal and slots

So yes, Qt does not use templates for signal and slots. There are drawbacks to this that are quite minimal:
- your namespace is "polluted" with the following macros: slots, signal, emit, SIGNAL, SLOT
- you have to pre-process your files through the moc.

However, the moc approach of Qt does have advantages. For example, it adds introspection feature to C++ which can be quite convenient. You can also dynamically load and connects Object.

If you write code only for the aesthethic of the result, then the debate "moc vs template signals" matters. If you write code to produce software, you don't care since both methods produce software that works. You will learn to use either in less than one day of coding.

By Philippe Fremy at Wed, 2004/04/14 - 5:00am

I don't know GTKmm but I find this line of argumentation always a bit - sorry - infantil. You say about yourself, that you are a C programmer but judges something (in practice) more or less unknown to you (C++/Qt) using buzzwords like 'modern'.
When compilers came out able to support templates, I used them with excitement. It is such a cooool language feature. It is - but it has his limitations. You will become aware of this, when you try something non-trivial with them - and trivial things too: I recommend you a search on the net for an article from Andrei Alexandrescu in "C++ report" (out of print) or "C++ user journal". He tries to implement there a max template max in an absolutely satisfying way. It wasn't successful - and Andrei was well aware of this (and mocked of himself). So, feateres alone are nothing.
To Qt:
They implemented their extensions in a very pragmatic, but still useful and sensible way. Give them a try and then come back.


By Micha Bieber at Thu, 2004/04/15 - 5:00am

Hi all, thanks.

These posts have been quite productive for me, as It was easy to read between lines that what the GTKmm people say is true, it's just that not many people find their arguments convincing.

Basicaly what I have learn from these posts is that QT is non-standard C++, limited by the support of old compilers, monolythic but complete and pragmatic. I already learn that "modern" is a buzzword and is non-sense but "have fun with it" is a deterministic technical feature.

And not forgetting the Propietary/GPL license, and not having even the GPL on Windows (and all my family use OpenOffice and Mozilla on Windows so please stop saying nonsese about free software on Windows beeing stupid).

Ok, if I choose to jump to C++ I have made my mind up clearly.

BTW: I am a C and PHP coder but make no GUI work by the moment, and no I have no time to test GTK and QT and C++ before choosing a GUI framework, that's why I made these comments, I just don't believe anybody's PR (neither GTKmm nor Trolltech) and need an independent opinion.

By Anonymous Lurker at Thu, 2004/04/15 - 5:00am

Qt is standard C++, otherwise it wouldn't compile with g++ obviously. And moc, BTW, is actually not a preprocessor, the only preprocessor used is the standard C++ preprocessor (well, at least if I understand the difference between a preprocessor and a code generator or whatever the proper name for this functionality is). In other words, Qt C++ code is compiled as is just like any other C++ code, and hence it's standard C++ as well. The difference between Qt and gtkmm is basically the fact that they're different.

By Luboš Luňák at Thu, 2004/04/15 - 5:00am

Yes, complaining about moc code generation is like complaining that it's wrong to generate code from a Qt Designer .ui file, because you should only have 'pure C++' in your project. After all C++ wouldn't be any fun if it wasn't 'difficult' - you need to show off to lesser programmers that you'd actually mastered it. And of course those 'hand crafted' widgets are so much better than any autogenerated nonsense from a .ui file.

But I'm personally not a fan of C++, although I can code in it, because I just find it too much of a headache. If I was a PHP/C programmer I think I'd try out PyQt or PyGtk perhaps, not C++. There is absolutely no such thing as 'C++ for Dummies', whichever toolkit you use it is very, very hard.

By Richard Dale at Thu, 2004/04/15 - 5:00am

The GTKmm people produce standards for C++? Wow. You learn something new every day.

By David at Thu, 2004/04/15 - 5:00am

>Ok, if I choose to jump to C++ I have made my mind up clearly.

This is seldom the case, if the mind has been burdened by too much emotions :->

The point, that you get here sarcastic answers is caused by your very own posting. 'modern!=good' and 'old!=bad'. In fact, these words alone have no meaning at all without careful evaluation. The technical points you missed in your flurry of excitement to remain independent have been brought to you by some other posters. I can only repeat my advice. Use the librariy(ies) and form a own view on them. Nobody here here will make you do something.


By Micha Bieber at Thu, 2004/04/15 - 5:00am

It would not be to get rid of the moc, but to have Qt use exceptions.

By Marc at Thu, 2004/04/15 - 5:00am

"An important note to all the readers, Qt is pronounced 'Cute' by its creators."

I always thought it was 'Q-T!'

By LuckySandal at Thu, 2004/04/15 - 5:00am

It is "Q-T" or "ku-te" which maybe sounds similar to "cute" if you are unfamiliar with norwegian.

By . at Fri, 2004/04/16 - 5:00am

Accoring to Matthias Kalle Dalheimer's excellent book, either pronunciation is good. I just say Q-T.

By David at Fri, 2004/04/16 - 5:00am

I presonally like "Cutie" better ;)

By JOY at Tue, 2008/01/15 - 6:00am

I just went to a Qt developer conference offered by ICS. The Trolltech representatives and the ICS training staff all pronounced it "Que-Tea" (Q-T), not "Cute".

By Qt Developer at Fri, 2008/08/01 - 5:00am