OSNews

They're definitely one of the better Austrian newspapers.

It was recorded as I see the camera behind me when sitting in on some of the talks. Not sure when they will appear but I'll ask a few people who should know.

I agree. The interview was extremely one-sided. If you google, you'll get the sense that the GTK community was as opposed to the idea of GTK3 as they could possibly be without being rude and dismissive. There are a number of issues at work here.

First, the major pain points for mobile and graphical developers are canvas library fragmentation and Cairo performance issues. Both of these are very pressing problems, but neither require breaking compatibility with GTK2. They need a solid canvas layer, and they're desperate enough to suggest looking at the Qt4 canvas for inspiration.

Next, the GTK project has somewhat serious organizational problems that are causing incremental development on GTK2 to proceed at an underwhelming pace. GTK-2.12 was supposed to be released in January. Then it was pushed back to March. The latest development tarball was released in June. GTK-2.12 is now over 6 months late and counting, and Nokia is pushing for a major overhaul. At this pace, we're looking at a release target in the next decade.

Also, the mobile developers are horrible at tracking progress. Most mobile GTK platforms are still stuck on GTK-2.6. This is like someone running Linux-2.6.5 bemoaning the recent progress in kernel development. You can only really drive progress in free software development if you're living somewhat close to the bleeding edge, at least in the development branch. The mobile developers got burned by the Cairo transition and their best hope is to plead for the GTK community to save them.

So it's not too far a stretch to interpret Nokia's calls for GTK3 as a sort of ultimatum. A lot of mobile and other commercial developers gleefully jumped on the GTK/GNOME bandwagon a couple years ago, and it hasn't been a slam dunk. In the interview, the Nokia guy explains that in order to write the applications they want to write, they either have to resort to other toolkits or go straight to the metal, and they don't want to do the latter. So either GTK shapes up, or they'll have to "resort" to another toolkit.

There's a fair bit of exciting development happening at the platform level of the GNOME environment. But toolkit development is different. It might be one of those areas where the cathedral works better than the bazaar. If you look at the KDE project, the vast majority of the community development is at the platform and application levels. They're glad to keep their participation in Qt mostly focused on feedback and hacking around the edges. Trolltech has been a godsend for the KDE project, and it seems like GNOME could use their own semi-commercial toolkit developer.

Something tells me Nokia is not interested. The most likely candidate? Probably a Google/Mozilla alliance. The GNOME roadmap increasingly seems headed the way of Web-2.0 as a desktop development framework. For better or worse...

Something tells me Nokia is not interested.

It doesn't sound as if Nokia is interested at all. To go for a GTK 3 they'd need to come up with a roadmap, a list of features they would need to see, they'd then need to start coding it and they'd then need to get into some politics with core GTK developers in pushing for the need for a GTK 3.

Something tells me that the GTK developers are not keen on that at all either, simply because it's a spectacular amount of work, requires a lot of development time and requires a lot of planning to come up with a universal toolkit that's good enough for what Nokia wants to do.

I've never really understood what Nokia were doing here. The Gnome platform they are using is only to be found on some tablets that few of their customers buy, their mobile phones continue to use Symbian and they're not willing to commit a lot of resources to it.

Nokia is probably interested in GTK/Gnome/Linux as possible way off symbian, or at least as a backup plan. So while they're still just experimenting and releasing what are basically proof of concept products, there is no doubt at least serious talk about to move some phones to GTK etc. if it ever becomes useable for what they want.

I think Nokia is just bitter because they are not used to approaching 'companies' about using they're technology and being told "We don't care about your needs".

If Nokia was so ready to jump on the Qt bandwagon, they would have done so in the first place. It seems to me that their main reason for creating Maemo was that they didn't want to pay Qt royalties. I doubt that's going to change anytime soon; they're more likely to hire more developers in the short term to create their own fork of GTK than face the prospect of paying Qt royalties indefinitely.

If that's true, they're extraordinary morons.

I don't think it is.

Edited 2007-08-13 11:03

It seems to me that their main reason for creating Maemo was that they didn't want to pay Qt royalties.

Well, like Sun, they've never came out and said that was a reason for using GTK and Gnome.

I doubt that's going to change anytime soon; they're more likely to hire more developers in the short term to create their own fork of GTK than face the prospect of paying Qt royalties indefinitely.

Interesting, and quite funny, economics you employ there. So Nokia are going to spend hundreds of thousands on developer salaries and resources to boost GTK and their development platform, whilst also spending money and resources on developers to create applications from that infrastructure, versus spending a few thousand on Qt licenses and only salaries for application developers?

If they GPL their software then there are no Qt license fees.

Edited 2007-08-13 16:00

Yes, the initial investment in creating a GTK+ based stack is obviously higher, but considering that they have the right to modify and even resell that stack, at no cost to them, indefinitely into the future, and the fact that they have absolute control over that stack, I can see why a company like Nokia--which likes custom, self-built solutions--would choose GTK over Qt, despite some technical limitations.

You hit the nail right on the head. With GTK+ they do need commercial development backing; what there needs is for Novell, Red Hat and Sun to sit down together and create a 'GTK+ consortium' - a independent stand along entity which is funded by Sun, Novell and Red Hat. Something like the Mozilla foundation. The focus for the developers is solely on the toolkit.

But it would require the three companies to put their ego's aside. That is what is holding GNOME from being *the* development platform for commercial software vendors - they need to know that there is a single desktop which they can focus their product development on. If they know that GTK+ is actually being developed by companies rather than being at the mercy of whether volunteers are willing and able to fix up issues, you'll find people will be more willing to entertain the idea of bringing big name applications to *NIX.

For me, as much as I would love to see GNOME take off, I just find it lacking in so many areas when compared to KDE. Global/System wide spelling checking for instance, a messenger that implements the MSN features such as custom emoticon support, webcam support and so forth. I know this isn't a 'GNOME vs. KDE' thread but one can't ignore the roles of these respective desktops have in the success or failure of *NIX on the desktop (what ever the *NIX maybe, be it OpenSolaris/Indiana, Linux or *BSD).

I agree with you. If they contributed in a significant way then it would happen. GTK+ needs far more people maintaining it than there currently is. HTK+ needs a huge overhaul, imho. I dond't understand why breaking abi is such a big deal. Just make it dead easy for devs to port to the newer abui and minimize any porting woes by providing tools to the devs. I really don't know why some of the resources going into gnome aren't transfered into GTK9+ which needs it the most, especially since it is the foundation behind all of gnomes services. It just seems kind of backwards to me. Also a more cross platform minded gtk wouldn't be a bad thing.

I dond't understand why breaking abi is such a big deal. Just make it dead easy for devs to port to the newer abui and minimize any porting woes by providing tools to the devs.

Sounds like Qt 4

Well, to be fair, I would say that Carlos, the interviewee, did provide some pointers about the current limitations of GTK.


"For me basically the main issue with GTK+ is that the kind of user experience we want to target is just not possible anymore to implement if you base it exclusively on the toolkit. If you want to have fluid animations or transitions in your UI, if you want to have free theming, if you want to have more freedom of expression for the layout, you can't all do this based on GTK+ currently.

So you could do that by resorting to other toolkits or by implementing it the hard way, going "straight to the metal" with Cairo or OpenGL, or using other libraries like pigment or clutter. But ultimately writing applications gets pretty hard, so you really want to have that in the toolkit, to maximize productivity.

One of the main points of the presentation was, that it becomes more and more clear, that without breaking ABI, it's just not possible to reach that level of support for this kind of user experience. That was the sort of the provocation in the meeting, how do you approach this with still keeping all those useful properties people have been relying on. A toolkit that has a stable API and a huge set of applications that are building on it. So to get some sort of strategy how to reach a balance to combine both goals, getting the UIs you want without disrupting the whole desktop."

I would say that part of the problem is that Nokia did not do its homework when choosing GTK and are now paying the price. They could move to another free toolkit or help improve GTK.

They would need to do a serious cost-benefit analysis to see where they are and what makes more financial sense in the medium and long term.

"I don't know why no big enterprise like IBM, Sun or even Nokia until now simply didn't buy Trolltech or Qt and turned it LGPL or abother free license for all purposes (including commercial developers)."

Word on the street has it that one certain big linux company tried to do that once. But the reality is: Nobody pays something like 200 Million Dollars for a toolkit when you can have another one for free, that would be insane from a business point of view.

And why wouldn't they just pay to use it for as much as they need? That money gets spend on improving it, just like it would if they would directly spend it. Besides, paying for and developing with Qt is often still cheaper than struggling with GTK...

And they have the KDE free Qt foundation who protects their interests in the long run.

Why would they buy it? It has a vibrant, growing company behind it, fully dedicated to it's quality. Offering support and services and securing it's future. Instead of LGPL-ing it, they should put such a company behind GTK, rewriting & GPL-ing it (or just switch to Qt, of course).

A toolkit is better off in the hands of a company, I think the last 10 years have proven that already. As long as there is a good 'deal' with this company (like KDE has in the KDE Free Qt Foundation - http://www.kde.org/whatiskde/kdefreeqtfoundation.php ).

I really don't think so. Both Qt and GTK+ provide solid foundations for developing applications, and neither has a clear "lead" over the other.

In another comment you wrote:


Do you have any research to back that up? Preferrably non-anecdotal. I would think that it much depends on the type of project, and who the developers are.

Well, I'm no developer myself, so I can't check GTK and Qt out for myself. Not that that would make a big diff, it depends on preferences and what you're used to anyway.

Yet, by the same means, one could argue KTHML and Gecko are both pretty hackable, and neither has a clear "lead" over the other... But most would disagree with you, especially those who know both codebases.

Except for those who really really hate C++ so much they'd rather brush their teeth with a grinder, I think most hackers say Qt is ahead off GTK.

Do you have any non-anecdotal research to back this up? By what metric is Qt "ahead"? One such metric could be the number of available applications:
- Gnome (1037 projects)
- GTK (1686 projects)
- KDE (845 projects)
- Qt (767 projects)
http://freshmeat.net/browse/229/

I'm not saying that this is a good metric - just giving an example... But sure, among C++ hackers Qt probably has a greater mindshare than GTKmm does. Maybe.

Both Qt and GTK+ provide solid foundations for developing applications, and neither has a clear "lead" over the other.

Given that Qt is powering through its 4.x cycle, and GTK can barely get through its 2.x cycle, let alone come up with a roadmap for 3.x, that gives you the answer to that one.

Do you have any research to back that up? Preferrably non-anecdotal.

You'd probably be better off asking Gnome developers that one, asking why they need a higher level language and asking why many people feel that the Mono framework is the answer to Gnome's development woes.

Well, Linux is at it's 2.x cycle as well and there's no roadmap for 3.x... The reason for changing version numbers is usually because you throw old code (or code design actually) out and replace it with something else. Sometimes it's design is so good that it doesn't have to be replaced for a while.

Oh, I have my doubts about number 4 being better, except for marketing or astrological purposes. There might be other reasons that the roadmap is different for both projects.

It could be, for example, that Qt1, Qt2 and Qt3 needed a complete overhaul because they sucked, while GTK+ 2 did not suck at all.

Or maybe Qt1, 2 and 3 did not completely suck, but it was not easy to move them forward and introduce new features the way they are being introduced all the time in GTK+, so they had to break compatibility three times over.

Not that you would care, but tremendous improvements in functionality have been added into Gnome and GTK since Gnome 2.0 times, and many improvements are pouring in all the time. The reason that GTK 3 is not coming soon is that what features are being proposed for it end up appearing into GTK 2.x.

As for why higher level languages, if you had written but 1K lines of C++ and 1K lines of Python, even with Qt's well-thought c++ api, you would know.

Anyway, whatever the reasons these projects behave as they do, it seems clear that it wont be you who clarifies them.

Absolutely!

I therefore find it questionable if it is the right way to push for GTK 3.0 through the media.

It is one thing to improve the foundations one has chosen for ones product, it is another to suggest that a major change is the only way out, just because the things one needs might be easier to get this way. A lot of other people might still find the current feature set and/or the way and pace of improvements to be sufficient for their needs.

I don't expect you to believe me, but having used both codebases, Qt definitely does have a very clear lead over GTK. The Qt API is clear and intuitive and the documentation is the best I've ever seen for any toolkit. Just compare the docs for a button in both toolkits:
http://developer.gnome.org/doc/API/gtk/gtkbutton.html
http://doc.trolltech.com/4.3/qpushbutton.html

The Qt docs have a description of the purpose of the button, the states it can take, different types of buttons available, an example of its use, and crosslinks to documentation on related subjects. Obviously a button is not that hard to understand, but these kinds of docs become invaluable for more complicated classes.

And in any non-trivial app, the GUI widgets are just a small part of the code. So when my app needs to connect to a database, communicate on the network, parse XML, store settings, use DBus, do multithreading, etc etc, I just use the appropriate Qt component. Sure, all these things are also possible if you're using GTK, but then you have to find the right external libraries that provide that functionality. Those libraries are going to have a different programming style, and you have to hunt down the ones that are the most mature of the bunch, and deal with version incompatibilities of all of them.



Well I doubt there is any "real" research out there, since no-one will do the same project twice with different toolkits. I think anecdotal evidence is all you'll find.

I believe you're linking to the GTK+ 1.x documentation for GtkButton, the newest version is here:

http://developer.gnome.org/doc/API/2.4/gtk/GtkButton.html

Not that this invalidates your point, but I personally feel the documentation is of about the same quality.

If you're writing GTK+ apps in the C API you're asking for a world of pain anyway...just don't do it...

Edited 2007-08-13 01:17

I most certainly believe you. You make a valid point, and your own personal experience is hardly anecdotal. Although your GTK+ experiences are dated, this is exactly what I was asking for. Thank you. But as you can see, there are people who disagree with you:
http://www.osnews.com/permalink.php?news_id=18444&comment_id=26...

Well, there is at least one more reason than that: Gtk is C friendly, Qt is not. Many developers are still using languages where C binding is the preferred and only acceptable method of support for libraries. Not only that, the C++ ABI situation on Linux is absolutely horrid.

I've spent years distributing a runtime game engine that is free-for-any-use but not open source and the C++ ABI situation has been no end of pain for me. Trying to build one binary that works on older and newer versions of GNU/Linux is painful at best.

However, if it wasn't for the C++ ABI issue, and the license issue, I personally would jump at the chance to use Qt for projects like mine that are free for commercial and personal use, just not open source.

My whole issue with KDE (and thus Qt) is that I think it is unacceptable to expect commercial developers to embrace a platform where they have to pay per-developer licensing fees to a single company for closed source commercial applications. That is why I currently cannot support KDE, at least in the context of business or commercial applications. I think it's great as a platform for those that demand all of their software be free or open source, but I'm not interested in that sort of platform.

No other widely known desktop platform requires developers to pay a single company licensing fees for the right to develop applications for their platorm. Developing applications for Mac OS X, Windows, GNOME, Xfce, GNUstep, Solaris, and other environments does not *require* any licensing fees to be paid, certainly not per-developer ones.

The arguments about paying a licensing fee for the OS, or for development tools is irrelevant as almost every developer is going to have those anyway. Technically, they're not required to purchase those, and they don't have to be licensed per-developer.

I wish some company had bought the rights to Qt and made it available under a business friendly license. Obviously, it would be commercial suicide for Trolltech to do so themselves.

Edited 2007-08-12 19:48

While I think the price of Qt is easily worth it, I agree that the license is probably the biggest factor in keeping people from using Qt. With Nokia's 770/N800 for example, I assume they used GTK to be more friendly to third party, closed source developers. Like you say, you don't want to force people to pay a license to develop for your device. Then again I don't really know if the choice of GTK encouraged any developers either. I don't see any third party apps for the Maemo platform that are not open source anyway (aside from Opera, and they use mostly their own toolkit anyway).

Look at it this way. If you're going to be paying to license a toolkit, you gain exactly zero benefit over a proprietary toolkit and you get into the same vendor-lock-in issues and forced obsolescence issues that plague proprietary vendors. And because you're not coding to a multi-vendor standard, you can't even switch to a competitor. If you're going the licensing route, multivendor J2ME is a much better better deal -- especially since you can even compile it for speed and the flaws and workarounds of J2ME are well documented and well known and there are scores of programmers who already have J2ME experience.

IMO, if Nokia were interested in switching away from Gtk+, IMO, they'd likely go FLTK or wxWidgets or XUL or some other unencumbered toolkit rather than switch to Qt.

Edited 2007-08-12 21:21

If you're going to be paying to license a toolkit, you gain exactly zero benefit over a proprietary toolkit and you get into the same vendor-lock-in issues and forced obsolescence issues that plague proprietary vendors.

Well no, because everyone can find out how Qt works. With enough demand, there would be compatible alternatives.

IMO, if Nokia were interested in switching away from Gtk+, IMO, they'd likely go FLTK or wxWidgets or XUL or some other unencumbered toolkit rather than switch to Qt.

They're going to have exactly the same problems that they're complaining about with GTK.

I understand what you were trying to say, i.e. need to buy a Qt "commercial" licence for using the KDE API in a closed source application, but I'd like to emphasis that, while it is obviously the preferred way of developing on KDE, it is my no means the only possible option.

KDE, as a platform, is - and has been for years - based on shared infrastructure used through IPC and common files. Very few cases would require a third party to to actually use KDE API, Qt or even C++, e.g. application plugins.

Well, sure, you can write GTK+ or wxwidgets apps and have them run in KDE. Or did you have something else in mind?

Yes, I had

I was referring to building upon the KDE platform, e.g. use KDE infrastructure such as wallet, KIO slaves, notification handling, etc.

In the case of using a different toolkit one might not have perferct visual integration, though it should be possible with wxWidgets, but it is not required to use the KDE libs for functional integration (obviously it would be the most convenient way)

I don't get this attitude. You want to build a closed source app off of which you supposedly want to make money, but you don't want to pay the license fees? So, you want your cake and you want it for free? Qt is a high quality product and the reason it is is because the core team is able to work on it, get paid to work on it and that's all they do. If you open source your app so others can get it for free then QT has no issue with you. So, open your app and license the support of it or whatever. Another thing, they sell you commercial licenses for support purposes so you can call and they will help you out. It isn't all just for the right of closing your app.

Edited 2007-08-12 21:24

A paid-for toolkit is OK. It's just that the price might be too high for many shops. If even Adobe, VMWare and Nero chose GTK+, not Qt for their Linux software, what can be said about smaller shops?

Also, it's perfectly OK, both morally and legally, to build closed source software without paying license fees. For that you have BSD- and LGPL-licensed libraries and toolkits.

If even Adobe, VMWare and Nero chose GTK+, not Qt for their Linux software, what can be said about smaller shops?

Well, one is entitled to ask if any of the software from those companies matters. They all just seemed to wheel in developers to knock together Linux versions of their software, and those people they employed had a preference for GTK.

In the case of Adobe, we all have good PDF readers that come with our desktop environments. Who needs Acrobat? There are a ton of things I can do with K3B that I can't with Nero, and K3B is free and is shipped with my system. Both Adobe and Nero have missed the boat there.

In the case of VMware, given that their software runs on multiple platforms I think they're silly not to use a cross-platform toolkit so they don't have to worry about such issues. Maintaining a GTK codebase for Linux and a Windows codebase for Windows for their console user interface just strikes me as daft. With Qt they could have exactly the same codebase between platforms, and run it on a Mac as well.

The latter doesn't seem to be a choice that has been made out of common sense.

On the other hand, Opera, Google (Earth), Skype, and VirtualBox chose Qt.. I don't think there is overwhelming evidence that commercial developers prefer one or the other.

Actually, Adobe used Qt to make Photoshop Elements and Album, IIRC.

If you open source your app so others can get it for free then QT has no issue with you. So, open your app and license the support of it or whatever.

Exactly. But at the same time, it's possible for developers to write closed-source GTK+ apps for free, and still make money without offering any support, isn't it? That seems like quite a proposition.

Perhaps Trolltech should follow your advice about licensing support and giving the product away for free...?

Edited 2007-08-13 04:09

I think it is unacceptable to expect commercial developers to embrace a platform where they have to pay per-developer licensing fees

If not commercial developers, who should pay licensing fees for development tools? Should all development tools be unconditionally gratis? Isn't this one of those "gotta spend money to make money" situations?

Also, Qt is not a platform. Although a platform vendor could conceivable restrict its platform to Qt applications, most platforms happily run applications based on a variety of toolkits. It's just a toolkit. You have a choice.

No other widely known desktop platform requires developers to pay a single company licensing fees for the right to develop applications for their platorm.

Don't you have to pay a per-seat licensing fee for Visual Studio? Even if you're making free software? Microsoft gets all the money, right?

I understand your position. You rather like Qt, perhaps better than any other toolkit, but you don't want to pay for it, even if you intend to profit from it. Maybe it's too expensive with respect to your projected revenues. Or maybe your time isn't valuable enough to warrant paying for convenience. Perfectly understandable.

But isn't Trolltech's business model also understandable? It's a value proposition. For some commercial developers, it's an outstanding value, and for others, it's not.

Also, Qt is not a platform. Although a platform vendor could conceivable restrict its platform to Qt applications, most platforms happily run applications based on a variety of toolkits. It's just a toolkit. You have a choice.

Ah, but KDE is a platform, and any product wanting to achieve the tightest integration possible with it must use KDE.

It is the "native" toolkit of the platform.


Don't you have to pay a per-seat licensing fee for Visual Studio? Even if you're making free software? Microsoft gets all the money, right?


No, actually.

First of all, you don't have to buy Visual Studio to develop commercial Windows Applications. You can use Visual Studio Express, MingW, Borland, etc. And most of those companies offer site-wide licensing or licenses that can be transferred as many times as you want between developers.

Trolltech, on the other hand, offers licenses that are per-developer only and that are limited to being transferred once every six months between developers.

Second of all, you have a choice between many different vendors for the same platform, and in the end, you still end up using the same native platform toolkit. Not so with KDE/Qt. Not only that, there are many *zero-cost* development options for Windows.

I understand your position. You rather like Qt, perhaps better than any other toolkit, but you don't want to pay for it, even if you intend to profit from it. Maybe it's too expensive with respect to your projected revenues. Or maybe your time isn't valuable enough to warrant paying for convenience. Perfectly understandable.

Apparently you don't understand my position. The point is, no other platform (talking about KDE) has a setup that *requires* a developer to pay licensing fees to a single vendor for closed source application development (it could even bee free-as-in-beer, but not open source). It is pretty sad when there is more competition in development tool providers in the Windows world than there is in the KDE world. Due to KDE's choice of Qt as their toolkit, developers are limited to chosing from a single vendor for their platform development needs if they want to achieve the highest level of integration possible with the platform.


But isn't Trolltech's business model also understandable? It's a value proposition. For some commercial developers, it's an outstanding value, and for others, it's not.

As I said earlier, that is why I wished someone had bought them out. Because it would obviously be commercial suicide for Trolltech to change their licensing terms. However, it is also understandable that commercial developers would complain about the *requirement* to pay licensing fees to a specific company just to build closed commercial or non-commercial applications for a platform (KDE).

Edited 2007-08-13 13:09

True, although I would argue that that is the way a lot of people like it. I don't have the time or the skill to argue this point with as much logic as Eric though, so I direct you to read this article instead.

http://www.ofb.biz/article.pl?sid=381