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

I'd vote for this. I think it would be easier and more efficient to use a template based implementation of signals and slots (similar to libsigc++). Most of the data typing would be done in compile time and it would be quickier.
I also think it would be better to drop obsoletes classes and use the STL's alternatives (containers, ...)

This is complete bs. If the worst thing you can say about a library is that you dont like the names, then you either like the library, or you have *no idea* what your talking about. The STL hierarchy is exactly as it should be, there is no reason, given the current scope of the STL why it should have a Java style hierarchy. As a matter of fact, it seems the only concern you have is that it doesnt *look* like Java. Pretty amature criticisms.

The naming is not a problem because I don't like it, but because it is not consistent when mixed with Qt/KDE naming schemes.

A Java-like hierarchy has several advantages. The most important is probably that it makes using collections as arguments for APIs much more convenient. In Java you can make a function take a (java.util.)Collection as argument, no matter whether it is actually a Map or a Set or whatever. With STL you have to chose one for the API, and the user must then convert his type to the APIs. Or alternatively, you overload the API function for each available STL collection class...

C++ uses genertics, which Java recently incorported into Java 1.5, which allows you to parameterize the containers type at compile time, so long as the passed type supports the used interface, it will work. This treads on some of the same ground as the Java heirarchy, and is exaclty how the STL is designed.

Will work nicely for sets or maps, or indeed any "Associative Container" as defined in the STL manual. If you do some googling, you can read about how "STL-like" ideas based on generics are being incorporated into the next Java 1.5.

As for the reason why its called push_back instead of append: STL is built upon certain concepts, such as Iterators, and there is a method called back() that returns an Iterator that points to the last element of a Sequence: therefore push_back pushes an item to where back points.

I know, but unfortunately the use of templates
a) makes formal documentation almost impossible. "Associative Container" is not a base class or any other C++ construct, it is a STL-description of classes that share common properties. I think the lack of systematic documentation is one of the worst problems with STL... in the end the only formal C++ description is in the methods implementation
b) The error text that you get when you use the wrong type is bad. You won't get "argument 2 is not a Associative Container", you will get something like "Cant find insert() in argument 2 in line 23". Almost completely useless, you can only fix it by reading the APIs documentation.
c) requires that you implement the function in the header

I didn't doubt that the STL designers have a logic explanation for "push_back" and every other detail of STL. But it is clearly obvious that is has not been designed the way it is for didactic reasons, or to make the developer type less. It has been designed for a very special form of aesthetics and purity, that may be nice for cod fetishists, but bad for those who just want to get their work done.

In case a, its not necessarily clear that formal documentation of the class hierarchy is any more useful than STL style models. I dont find STL, havin read the documentation, less clear than Java. Certainly taken with case b, no one has ever claimed that C++ doesnt give you a lot of rope to hang yourself with. C++ is harder to use, but still more powerful than Java. However well done software will *always* require the programmer know the API well. Indeed Java seems quite popular with lower rung programmers precisely because it is easier. But C++ and STL are still mainstays of large scale programming.

With case c, the actual languae doesnt require implementing in the header, this is a hack for working with compilers, like GCC, that dont implement the export keyword. A more acceptable version is simply including the cc file. Either way its a C++/Compiler issues, not STL issue.

C++ aint perfect, but STL is an example of what power and elegance can be accompilshed with the language. Other than that, we should probably just agree to disagree.

The STL doesn't have a class hierarchy on purpose. You shouldn't use STL containers in your API. You should pass iterator ranges (see the algorithm provided by STL).

This way you can use your methods with several different STL collection classes like you can with Java. Your methods will be even usable with collection classes that are not part of the STL but which were created by 3rd party developers with the needed STL typedefs.

You're raising a very good issue. Basically, the moc approach and the libsigc++
approach raise the classical static vs. dynamic binding tradeoff. The former is
faster, and is compile-time typechecked. The latter is slower, run-time typechecked -- but also more flexible, since you can do things like accessing
slots by name at runtime, so you can have two things talk to each other without a base interface class (which may be inconvenient to distribute for some reason), or do things like the Qt/DCOP bridge, or the various bindings, etc.
(Some people would insist that the former approach is more consistent with the C++ design, but I'd say that the C++ design it to provide multiple methods of programming, so the developer can decide which one is more appropriate to the conitions -- which of course means there is nothing wrong with adding an another approach... but I digress)

What, don't you know? KDE is a joint venture of SuSE and Trolltech. They *own* KDE. That's why Trolltech marketers feel free to use KDE mailing lists to push their stuff. That's why SuSE employees get to make radical changes to KDE CVS without a peep of discussion on kde-core-devel. Trolltech houses www.kde.org. SuSE houses cvs.kde.org, so KDE lives at their whim.

What's that? You're asking me for proof that SuSE and Trolltech influence KDE policies? That's easy to show. Let's just check the kde-ev-membership or kde-ev-board archives.. oh, they're not open. Let's check kde-security.. oh, that's not open. Let's check kde-packaging... oops. kde-sysadmin? Same story. So you're right, I have no direct evidence, only circumstantial. But likewise, SuSE and Trolltech defenders can't refute anything becuase of the same lack of evidence.

In closing, yes, I'm fully prepared to get bashed for daring to criticize the employer/sponsor of KOffice RC Luká? Tinkl (hm, kdenews.org maintainers: make the site utf8!!!), Konqueror head David Faure, former KDE RC Waldo Bastian, KMail co-maintainer Don Sanders, KDE founder Matthias Ettrich, etc. I'm fairly likely to be accused of making personal attacks on them. But look at it this way: when these two companies hold so much power in KDE, shouldn't they be held to a higher, not a lower, standard? I think so. I also think the case for defending them is pretty weak if the only answer is to call any questioning of them a personal attack.

What a FUD. A new web server is no problem and I heard Savannah offered to host KDE CVS. You have access to kde-ev-membership archive, so risk it to be excluded and post your proofs. And for kde-security not being open, what a proof for a SuSE and Trolltech conspiracy!

KDE-security not being open is indeed a big problem. I can understand why it's not a public mailinglist, to avoid black hats from subscribing, but I would say every KDE developer entrusted with a CVS account should be trusted on that list, no?

If I wanted to exploit a security hole in KDE, I could easily write one. There are several applications in CVS which are barely maintained and a malicious developer could easily sneak in commits that wouldn't be properly reviewed. Closing kde-security means that a special group apparently does not have to trust the majority of developers, while the larger group has no choice but to trust the small one. That's simply not a healthy way to organize matters.

Same for the packaging: some developers want to abandon the idealogy that KDE provides source packages only, hence the weird release schedule these days where, except for those on kde-packaging, noone really knows what versions of the code are released and when. In all honesty, I have not tried subscribing to kde-packaging. I ought to, as I release (and package) stand-alone versions of my software in KDE for users of KDE 3.0 and for practical purposes I'd like them to have the same versions that would be part of a normal KDE release.

As for unreviewed CVS commits: that happened just once, prior to the KDE 3.0 release. Well, an unfinished Crystal (http://bugs.kde.org/show_bug.cgi?id=51048) was pushed through for 3.1 as well, but apparently I'm the only one who thinks it is ridiculous to make an unfinished look the default.

On one hand, I can't blame companies like SuSE for employing the top KDE developers. On the other hand, since that is probably the best way to influence KDE development, I also can't blame people for having second thoughts about it.

I'm still hoping that Philipe can concentrate on question relevant for KDE in the interview. If that happens, it will be valuable. If I want Trolltech's company profile, I'll visit their website.

what do SuSe and Trolltech have to do with certain mailing lists being members-only? last time i checked, the kde-ev list was for members only because, well, it's a place for members of kde-ev to discuss issues that pertain only to kde-ev. it's a small thing called privacy and discretion, and in this case has nothing to do with SuSe and TT.

as for those two companies employing several key contributors to KDE, you're right. that gives those organizations more say in what occurs simply because they have more individuals working on KDE with their interests in mind. those interests, however, are not at odds with KDE. not only that, but the majority of KDE developers are not employed by either of those companies. any group of developers that got together and decided to do a certain amount of work on KDE's code base would have a proportional say in what code gets written. that's how it works.

it isn't like the release dude is always a SuSe or TT hire, either. that would go a long ways to supporting your theory, but the last release dude (Dirk Mueller) wasn't paid by anyone to work on KDE!

non-Suse/TT hires often overrule the desires/thought/code of SuSe/TT employees working on KDE. by providing reasonable code with reasonable explanation and discussion, there have been times when their better judgement at that time was overruled. the opposite is true as well. most often, the outcome is something better than either person(s) would've come up with on their own, regardless of who pays their wages.

as for who "owns" KDE, well... it's all under free software licenses, now isn't it? and a lot of different people own the copyrights of various pieces. you even "own" some of those copyrights, Neil. i'm also not certain what you're referring to when you say "Trolltech marketers push their stuff on KDE mailing lists"? perhaps you'd care to clarify.

SuSe and TT are both doing great things for KDE by providing financial and marketing support for the platform. they have not taken any special place in the project beyond that which would be afforded anyone who did what those contributors are or have done.

you seem to care quite a bit about KDE. i wonder how constructive for KDE your innacurate comments are?

As long as you think Trolltech's interests are perfectly aligned with KDE, and SuSE's are, too, then I guess you would not see these companies' pervasive influence as a threat. But how can we be sure just how influential these people are in release issues when basic lists like packaging and security are closed off?

You expect us to take it on faith, that these companies can be trusted to work with KDE, but I think trust needs to be earned. Both are companies that use or abandon free software licensing at a whim. That kind of behavior is detrimental to the community, and makes them seem less, rather than more, trustworthy.

it's only partially true that one needs to think that their interests are "perfectly aligned" with KDE. there is the counter ballancing effect of all the other developers in the project, as well. being Free software, their changes if determined detrimental, can be avoided.

as for having earned trust, i don't know how much more those who work for them and work on KDE could do to help improve KDE beyond where it is. they have provided art, coding, testing and marketing to date that has been in KDE's interest. what, besides their track record with KDE to date, are you looking for?

as for abandoning Free software licensing, i see both companies as actually having moved closer towards Free software licensing over time. i think it is obvious that both TrollTech and SuSe have more Free software under acceptable licenses in their stables today than ever.

as for the packaging list being closed, i believe there are reasons for that. best to ask those on the list, however. but the term "closed" is something of a misnomer, as last i knew it was pretty trivial to get yourself subscribed to that list: you simply had to be involved in the packaging of KDE for an OS.

the security list being closed is another obvious one. there needs to be a place where security issues can be reported, discussed, fixed and those fixes tested before announced and released to the public. full disclosure is good, but it needs to be accompanied with full fixes too. ;-) those subscribed to the security list are those who are directly involved in ensuring these matters get taken care of in a timely manner with the best results possible for the users. if security flaws were reported and not fixed, i'd be concerned. but KDE seems to be doing quite well when it comes to response times and effectivity to major security issues.

i agree that vigilent and careful attention should be payed to interests that get involved with KDE, be they corporate, communal, or individual. i don't believe in unwarranted boat rocking that only makes participation less attractive to those who have and are doing a great job. =)

Will there be any ada binding for qt.
Ada is a very powerfull language, and f.e. very big in france.
For a project with client + server in Ada we did need a
GUI. So we had to use the ada gtk bindings. But
that was very frustrating at much points.

Actually I've been working in Ada bindings for Qt. They're in a very early state, though. Currently you can instance most Qt classes and call most methods, but you can't derive classes, which disallows many possibilities. Also there's no documentation whatsoever and I'm not ready to release the binding generator I'm using to create them. I'll try to finish the bindings if I've got time.

By the way, I'm not entirely sure Ada is the best language to program a GUI in :-).

> Actually I've been working in Ada bindings for Qt
Thats really great. I hope we will hear more from you!
I there any way to help you?

>By the way, I'm not entirely sure Ada is the best language to program a GUI in :-).
Thats right. But Ada is a great language for
embedded and safety critical systems. It has the stronges cast checking
i'v seen, and has much allready inside like tasking.

I think when (if) the bindings are ready to be released I will announce them to the kde-bindings mailing list, so you should watch it if you're interested. Don't hold your breath though, it will take probably at least a couple months at the very minimum.

So ok, I'm very influenced by the Mac OS X 10.2 (and 10.3 preview), and I think that should be the goal for the Qt/KDE-4.0 as it's the only really cool OS around at the moment and why put your goals any lower?

Let me see... no comments about their patent on the bytecode interpreter of the freetype thingy, still suing people that try to imitate any of their styles in their (free, for non-profit) projects,... to say short: "I'll take as much of yours, but I won't give you back anything if I can"

Will Qt ever gain support for DirectFb, so one could run a fast desktop without the need of X11? It would make things like transparency much easier, and seing GTK allready been ported, it would be very nice to have Qt ported as well so we can run KDE on DirectFb.

Because it can save you a lot of overhead you don't need for most desktop systems. I mean: how many desktop users are actually running applications on other computers who's output they redirect? Not many, I'll warrant. The architecture of DirectFB is different from that of X, making graphics for the desktops and stuff like hardware acceleration much easier.

The majority of users runs applications with different permissions. Usually with root and their own user on the same screen. My guestimate of the effort of running X11 also over TCP instead of only named pipes would be 100 lines of code (out of > 1 million). And even the multi-user capability should be far below 1% of the overall code...

3. Qt Designer modularisation -
Will Qt designer be split up into components so that the relevant parts can reasonably be embedded in Kdevelop and the KOffice products - ( this is needed to match MSOffice.) - and not bring along the sicko MDI baggage...

4. QSA.
Is the licence interpretation for QSA incredibly restrictive? If I made eg KSpread have QSA scripting architecture, and someone made a QDialog using the exposed Qt APIs, this would place their entire spreadsheet under the GPL. This is clearly entirely unacceptable to many large organisations who love to throw spreadsheets at each other with big NDAs attached. Is it your position that a QT scripting architecture can never be non viral GPL to documents? Ie is it illegal to view HTML forms in Konqueror, which end up calling Qt widgets? I assume so... this is a very important question..

Also, will the QSA support other languages than ecmascript? ie python.. also, why not use KJS?

5. Do high profile, corporate open source apps going to GTK+ (Eclipse, Mozilla, ) purely for the LGPL ever make you wonder about your licencing? Do you ever wish IBM or Apple would buy you and LGPL Qt so you could *really* take over the world with your superior technology?

6. How much work do Trolltech put into X11 performance? Do you ever contribute to XFree86?

This is a very pertinent question even though it is political and not technical. I really am curious what TT thinks, although I doubt you can get a candid answer in a public interview.

Everyone should know about the SCO suit against IBM which is spreading heaps of FUD about Linux and free software more generally. Besides nebulous contract claims in the suit against IBM, they have very actively claimed that Linux is tainted by code or concepts that belong to SCO. It all seems to be a desperate attempt to extort money by a company whose products are now totally uncompetitive. The major power behind SCO is a technology investment firm called the Canopy Group. This firm is clearly behind SCO's recent strategy and has worked to arrange legal council and make other management decisions.

Finally the connection to Trolltech: The Canopy Group and SCO own a 5.7% stake in TT. This is not a particularly large portion of a company that is 64.7% employee-owned. What influence does the Canopy Group have on management of TT? What kind of privileged information are they entitled to as investors? Are any other owners of TT uncomfortable with the Canopy Group's position in the SCO case? Would it even be possible to buy out the Canopy Group's stake? Any discussions about that?

I'm too concerned about the origin of TrollTech money resources. What happens if the canopy takes control over TT an then say "KDE is our IP"?.
If this is just my mind flying away i wanna be sure not to be sue by SCO.
By the way I'm from México and the Law here permit us to sue SCO upon a
"Organized Gang Operation" = "Crimen Organizado" style with blackmailing customers
before they pay a "nonexistent" service invoice.