Linked by Thom Holwerda on Sun 12th Aug 2007 15:52 UTC, submitted by zaboing
PDAs, Cellphones, Wireless "A few months ago, the GNOME Mobile Platform was announced to the public. One of the main forces behind the launch of this initiative was Nokia, which uses a lot of GNOME-components in its Linux-based Internet Tablets Nokia 770 and N800. During this years GUADEC Andreas Proschofsky had the chance to sit down with Carlos Guerreiro, Nokias Manager for Open Source Software, to talk - amidst other things - about the not so different needs of personal computers and mobile devices, about the necessity for GTK+ 3.0 and the impact of the iPhone launch."
Order by: Score:
Good interview again
by Anonumous on Sun 12th Aug 2007 17:16 UTC
Anonumous
Member since:
2007-06-13

Second one fron GUADEC.

I don't know much about derStandard.at but juding from these two interviews, they have some good reporters. ;)

Reply Score: 5

RE: Good interview again
by Moochman on Mon 13th Aug 2007 03:33 UTC in reply to "Good interview again"
Moochman Member since:
2005-07-06

They're definitely one of the better Austrian newspapers.

Reply Score: 3

videos?
by pinky on Sun 12th Aug 2007 17:31 UTC
pinky
Member since:
2005-07-15

At all GUADEC webpages you can find something like this "Video License: Yes, Attribution-Share Alike" but no video.

Does someone know if GUADEC was recorded and if yes, where can i find the videos?

Reply Score: 3

RE: videos?
by SlackerJack on Sun 12th Aug 2007 18:18 UTC in reply to "videos?"
SlackerJack Member since:
2005-11-12

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.

Reply Score: 2

GTK 3.0
by kaiwai on Sun 12th Aug 2007 17:49 UTC
kaiwai
Member since:
2005-07-06

I'm sorry but the chap from Nokia fails to do one thing; justify why compatibility needs to be broken and GTK needs to exist. Are there things he and his organisation wants to do to with GTK that can't be done because of constraints? its very light on details about the issues.

Also, its all very nice talking and talking, but when there is little in the way of contribution to the heavy lifting of GTK+ (which is a damn small team of contributors given out critical it is) by Nokia, I find it hypocritical them whining on the sidelines and yet providing very little in the way of man power.

Reply Score: 15

RE: GTK 3.0
by butters on Sun 12th Aug 2007 19:22 UTC in reply to "GTK 3.0"
butters Member since:
2005-07-08

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...

Reply Score: 14

RE[2]: GTK 3.0
by segedunum on Sun 12th Aug 2007 20:49 UTC in reply to "RE: GTK 3.0"
segedunum Member since:
2005-07-06

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.

Reply Score: 2

RE[3]: GTK 3.0
by dagw on Mon 13th Aug 2007 11:05 UTC in reply to "RE[2]: GTK 3.0"
dagw Member since:
2005-07-06

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".

Reply Score: 3

RE[2]: GTK 3.0
by Moochman on Mon 13th Aug 2007 03:39 UTC in reply to "RE: GTK 3.0"
Moochman Member since:
2005-07-06

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.

Reply Score: 3

RE[3]: GTK 3.0
by vegai on Mon 13th Aug 2007 11:03 UTC in reply to "RE[2]: GTK 3.0"
vegai Member since:
2005-12-25

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

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

I don't think it is.

Edited 2007-08-13 11:03

Reply Score: 0

RE[3]: GTK 3.0
by segedunum on Mon 13th Aug 2007 15:58 UTC in reply to "RE[2]: GTK 3.0"
segedunum Member since:
2005-07-06

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

Reply Score: 4

RE[4]: GTK 3.0
by Moochman on Tue 14th Aug 2007 00:52 UTC in reply to "RE[3]: GTK 3.0"
Moochman Member since:
2005-07-06

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.

Reply Score: 2

RE[5]: GTK 3.0
by segedunum on Tue 14th Aug 2007 17:33 UTC in reply to "RE[4]: GTK 3.0"
segedunum Member since:
2005-07-06

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...

Just how and why are they going to do that?

What you're basically saying there is that Nokia can go and maintain GTK. That's just far too expensive to do, and pretty daft, and they've shown no indication at all that they're going to do anything other than complain about GTK.

Reply Score: 3

RE[2]: GTK 3.0
by kaiwai on Mon 13th Aug 2007 10:58 UTC in reply to "RE: GTK 3.0"
kaiwai Member since:
2005-07-06

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.


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).

Reply Score: 7

RE: GTK 3.0
by apoclypse on Sun 12th Aug 2007 19:26 UTC in reply to "GTK 3.0"
apoclypse Member since:
2007-02-17

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.

Reply Score: 6

RE[2]: GTK 3.0
by Moochman on Mon 13th Aug 2007 03:41 UTC in reply to "RE: GTK 3.0"
Moochman Member since:
2005-07-06

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 ;)

Reply Score: 2

RE: GTK 3.0
by porcel on Sun 12th Aug 2007 19:34 UTC in reply to "GTK 3.0"
porcel Member since:
2006-01-28

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.

Reply Score: 8

Qt
by shiva on Sun 12th Aug 2007 19:30 UTC
shiva
Member since:
2007-01-24

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).

QT, specially Qt 4.x, is superior to GTK+ and the only reason of Qt rejection is its dual license scheme (paid for closed app developing and free for free software developing).

Probably tt would be cheaper than develop another GUI frameworks/libraries and it would be a big contribution to popularize linux on desktops.

Edited 2007-08-12 19:31

Reply Score: 12

RE: Qt
by zaboing on Sun 12th Aug 2007 19:35 UTC in reply to "Qt"
zaboing Member since:
2007-04-17

"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.

Reply Score: 2

RE[2]: Qt
by superstoned on Sun 12th Aug 2007 19:38 UTC in reply to "RE: Qt"
superstoned Member since:
2005-07-07

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.

Reply Score: 5

RE: Qt
by superstoned on Sun 12th Aug 2007 19:36 UTC in reply to "Qt"
superstoned Member since:
2005-07-07

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 ).

Reply Score: 7

RE[2]: Qt
by kelvin on Sun 12th Aug 2007 20:17 UTC in reply to "RE: Qt"
kelvin Member since:
2005-07-06

A toolkit is better off in the hands of a company, I think the last 10 years have proven that already.


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:
Besides, paying for and developing with Qt is often still cheaper than struggling with GTK...


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.

Reply Score: 2

RE[3]: Qt
by superstoned on Sun 12th Aug 2007 20:31 UTC in reply to "RE[2]: Qt"
superstoned Member since:
2005-07-07

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.

Reply Score: 3

RE[4]: Qt
by kelvin on Sun 12th Aug 2007 21:03 UTC in reply to "RE[3]: Qt"
kelvin Member since:
2005-07-06

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.

Reply Score: 6

RE[5]: Qt
by superstoned on Sun 12th Aug 2007 21:34 UTC in reply to "RE[4]: Qt"
superstoned Member since:
2005-07-07

By what metric is Qt "ahead"?

How easy it is to use and how quick and efficiently you can write an application with it... Of course, in choosing a technology, more than quality plays a role. So that's obviously skewed.

Reply Score: 2

RE[6]: Qt
by kelvin on Sun 12th Aug 2007 21:51 UTC in reply to "RE[5]: Qt"
kelvin Member since:
2005-07-06

How easy it is to use and how quick and efficiently you can write an application with it...


That's a good metric. Do you have any research to support the position that Qt is better than GTK+ in this area?

Reply Score: 4

RE[7]: Qt
by yokem55 on Sun 12th Aug 2007 22:11 UTC in reply to "RE[6]: Qt"
yokem55 Member since:
2005-07-06

Well, in my opinion, the productivity of the smaller KDE development community (among whom far fewer are paid to work on KDE) is evidence number one that QT provides for a more productive development environment than GTK.

Reply Score: 1

RE[5]: Qt
by diegocg on Mon 13th Aug 2007 00:53 UTC in reply to "RE[4]: Qt"
diegocg Member since:
2005-07-08

He problably meant "technically"

Reply Score: 2

RE[5]: Qt
by l3v1 on Mon 13th Aug 2007 10:09 UTC in reply to "RE[4]: Qt"
l3v1 Member since:
2005-07-06

I'm not saying that this is a good metric


Good, because it certainly isn't. The technical level of those projects, the diversity of those projects, and the usage of their products would be somewhat more meaningful, yet still useless to judge the issue at hand. Professional developers knowing both would be the ones to start giving more usable insights.

Reply Score: 4

RE[3]: Qt
by segedunum on Sun 12th Aug 2007 20:44 UTC in reply to "RE[2]: Qt"
segedunum Member since:
2005-07-06

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.

Reply Score: 2

RE[4]: Qt
by samuellb on Sun 12th Aug 2007 21:01 UTC in reply to "RE[3]: Qt"
samuellb Member since:
2006-11-11

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.


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.

Reply Score: 6

RE[5]: Qt
by segedunum on Sun 12th Aug 2007 21:29 UTC in reply to "RE[4]: Qt"
segedunum Member since:
2005-07-06

Well, Linux is at it's 2.x cycle as well and there's no roadmap for 3.x...

Developers seem to have no trouble pushing out 2.x kernel versions, and each version is packed with a lot of different and new features. GTK just seems to have difficulty doing that.

Reply Score: 2

RE[4]: Qt
by Lobotomik on Mon 13th Aug 2007 19:26 UTC in reply to "RE[3]: Qt"
Lobotomik Member since:
2006-01-03

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.

Reply Score: 2

RE[3]: Qt
by anda_skoa on Sun 12th Aug 2007 20:52 UTC in reply to "RE[2]: Qt"
anda_skoa Member since:
2005-07-07

I would think that it much depends on the type of project, and who the developers are.


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.

Reply Score: 2

RE[3]: Qt
by leos on Sun 12th Aug 2007 23:22 UTC in reply to "RE[2]: Qt"
leos Member since:
2005-09-21

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.


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.

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 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.

Reply Score: 9

RE[4]: Qt
by baadger on Mon 13th Aug 2007 01:10 UTC in reply to "RE[3]: Qt"
baadger Member since:
2006-08-29

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

Reply Score: 7

RE[5]: Qt
by leos on Mon 13th Aug 2007 02:44 UTC in reply to "RE[4]: Qt"
leos Member since:
2005-09-21

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


Ooops sorry. I just searched for GTK reference documentation and picked the first link. It's been a while since I've done any GTK work.

Reply Score: 2

RE[5]: Qt
by l3v1 on Mon 13th Aug 2007 10:13 UTC in reply to "RE[4]: Qt"
l3v1 Member since:
2005-07-06

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


Having just checked both, carefully, I have to disagree. I find the qt documentation version a bit more usable. For a pro, the difference is not that much, given that the necessary information is there in both.

Reply Score: 4

RE[4]: Qt
by kelvin on Mon 13th Aug 2007 05:52 UTC in reply to "RE[3]: Qt"
kelvin Member since:
2005-07-06

I don't expect you to believe me


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=262867

Reply Score: 2

RE[5]: Qt
by superstoned on Mon 13th Aug 2007 09:14 UTC in reply to "RE[4]: Qt"
superstoned Member since:
2005-07-07

Of course someone disagrees. We're a huge community... In the thread you refer to, he mentions GTKmm as a GOOD example of C++ API/bindings. Now I ask you, did you EVER find ANYONE say ANYTHING positive about GTKmm? If so, you must have read a lot of comments on that topic, this is MY first... Everyone who had dealings with GTKmm I talked to complained about how horrible it is, and how clean and neath Qt is. But yeah, someone disagrees, so it must be a great API?

Reply Score: 5

RE: Qt
by binarycrusader on Sun 12th Aug 2007 19:44 UTC in reply to "Qt"
binarycrusader Member since:
2005-07-06

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

Reply Score: 9

RE[2]: Qt
by leos on Sun 12th Aug 2007 20:05 UTC in reply to "RE: Qt"
leos Member since:
2005-09-21

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.


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).

Reply Score: 5

RE[3]: Qt
by g2devi on Sun 12th Aug 2007 21:18 UTC in reply to "RE[2]: Qt"
g2devi Member since:
2005-07-09

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

Reply Score: 3

RE[4]: Qt
by segedunum on Sun 12th Aug 2007 21:38 UTC in reply to "RE[3]: Qt"
segedunum Member since:
2005-07-06

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.

Reply Score: 1

RE[5]: Qt
by superstoned on Mon 13th Aug 2007 09:15 UTC in reply to "RE[4]: Qt"
superstoned Member since:
2005-07-07

And they won't have support. I don't understand why a company wants to use a toolkit without a chance of commercial support, especially when it doesn't have great documentation nor a huge and dependable development community...

Reply Score: 5

RE[2]: Qt
by anda_skoa on Sun 12th Aug 2007 20:20 UTC in reply to "RE: Qt"
anda_skoa Member since:
2005-07-07

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.


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.

Reply Score: 4

RE[3]: Qt
by Moochman on Mon 13th Aug 2007 03:54 UTC in reply to "RE[2]: Qt"
Moochman Member since:
2005-07-06

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

Reply Score: 2

RE[4]: Qt
by anda_skoa on Mon 13th Aug 2007 10:22 UTC in reply to "RE[3]: Qt"
anda_skoa Member since:
2005-07-07

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)

Reply Score: 2

RE[2]: Qt
by rhavenn on Sun 12th Aug 2007 21:24 UTC in reply to "RE: Qt"
rhavenn Member since:
2006-05-12

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.


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

Reply Score: 9

RE[3]: Qt
by Temcat on Sun 12th Aug 2007 22:00 UTC in reply to "RE[2]: Qt"
Temcat Member since:
2005-10-18

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.

Reply Score: 6

RE[4]: Qt
by segedunum on Mon 13th Aug 2007 00:33 UTC in reply to "RE[3]: Qt"
segedunum Member since:
2005-07-06

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.

Reply Score: 4

RE[5]: Qt
by Temcat on Mon 13th Aug 2007 13:00 UTC in reply to "RE[4]: Qt"
Temcat Member since:
2005-10-18

Well, one is entitled to ask if any of the software from those companies matters.

That is indeed an interesting question, but the answer to it happens to somehow prove my point. It all boils down to the definition of "matters", and in the closed source world (from the developer POV, since we talk about choosing toolkits) this means simply "generates revenue." For the apps that generate less revenue using Qt with its rather steep per-developer fees might not be economically justified - you won't get the ROI.

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.

Are you sure they are just silly? Do you have access to their data? Can you prove that maintaining two versions is indeed more expensive than paying for Qt? It's not at all clear and depends on many factors.

Besides, GTK+ is a cross-platform toolkit. Most of my gripes with GTK+ on Windows are removed by now (especially if one uses native common dialogs like for example Abiword). There are some smaller quirks (see pane resizing in Sylpheed on Windows), but AFAICS they group around some very specific use cases.

Reply Score: 2

RE[4]: Qt
by leos on Mon 13th Aug 2007 00:49 UTC in reply to "RE[3]: Qt"
leos Member since:
2005-09-21

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?


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.

Reply Score: 6

RE[5]: Qt
by baadger on Mon 13th Aug 2007 01:07 UTC in reply to "RE[4]: Qt"
baadger Member since:
2006-08-29

Actually Google Earth for Linux uses it's own bundled version of Wine. So no 'native' toolkit at all.

Opera use QT but *seem* to have written their own GU abstraction toolkit (or atleast skinning engine) for in webpage form elements since these, as is the rest of Opera, are skinnable. Opera's dialog's, when skinned, do not match the main menu style (which looks 'native' QT).

All in all, the situation regarding GUI toolkits on Free Desktop's is a community dividing one. People (in my experience) don't tend to use QT apps under Gnome or GTK+ apps under KDE. It just feels wrong somehow, and both toolkits and their respective DE's have their own philosophies.

Btw, those wanting homogenous GTK+ and QT themes might want to look at "QtCurve".

Reply Score: 2

RE[6]: Qt
by leos on Mon 13th Aug 2007 02:40 UTC in reply to "RE[5]: Qt"
leos Member since:
2005-09-21

Actually Google Earth for Linux uses it's own bundled version of Wine. So no 'native' toolkit at all.


Google Earth uses Qt 3. A quick google search will reveal that. Or just check at the libs it loads
http://slashdot.org/comments.pl?sid=188273&cid=15519884

You may be thinking of Picasa, which uses Wine to run on Linux
http://slashdot.org/article.pl?sid=06/05/26/0310229

Opera use QT but *seem* to have written their own GU abstraction toolkit


Yup, last I heard most of their UI is their own toolkit. Some things like menus and printing support uses Qt.

All in all, the situation regarding GUI toolkits on Free Desktop's is a community dividing one. People (in my experience) don't tend to use QT apps under Gnome or GTK+ apps under KDE. It just feels wrong somehow, and both toolkits and their respective DE's have their own philosophies.


More or less. I try to stay away from GTK apps on my KDE desktop, just because I don't know any of them that don't have a Qt based counterpart, and running just one toolkit saves resources. Would be nice of course if that situation didn't exist, but there isn't anything that can be done about the situation.

Reply Score: 7

RE[4]: Qt
by Moochman on Mon 13th Aug 2007 03:59 UTC in reply to "RE[3]: Qt"
Moochman Member since:
2005-07-06

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

Reply Score: 4

RE[5]: Qt
by Temcat on Mon 13th Aug 2007 12:31 UTC in reply to "RE[4]: Qt"
Temcat Member since:
2005-10-18

Yeah, but they used GTK+ for Reader.

Reply Score: 2

RE[3]: Qt
by Moochman on Mon 13th Aug 2007 03:58 UTC in reply to "RE[2]: Qt"
Moochman Member since:
2005-07-06

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

Reply Score: 3

RE[2]: Qt
by butters on Mon 13th Aug 2007 01:43 UTC in reply to "RE: Qt"
butters Member since:
2005-07-08

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.

Reply Score: 7

RE[3]: Qt
by binarycrusader on Mon 13th Aug 2007 13:03 UTC in reply to "RE[2]: Qt"
binarycrusader Member since:
2005-07-06


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

Reply Score: 4

RE[4]: Qt
by leos on Mon 13th Aug 2007 15:40 UTC in reply to "RE[3]: Qt"
leos Member since:
2005-09-21

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 be free-as-in-beer, but not open source).


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

Reply Score: 5

RE[4]: Qt
by anda_skoa on Mon 13th Aug 2007 18:20 UTC in reply to "RE[3]: Qt"
anda_skoa Member since:
2005-07-07

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


Hmm, well, obviously tightest, being the superlative, can only be achives using the KDE API.

Though I would need to see a good example - good as in likely to be interesting for a third party application - where this would be necessary.

As a counter example, if an application would be using wxWidgets and, assuming interest in visual integration, the system would provide a KDE based implementation, it would be mostly indistinguishable from a "real KDE" application from a user's point of view.

It is unfortunately a common misinterpretation that some technology, be it Qt or C++, would be *required*, while it is basically just *extraordinary convenient*

Anyway, in my opinion the added value of using the framework directly does make it even more worthwhile to invest in an appropriate Qt licence, just in case the framework offered by Qt alone is not enough.

Reply Score: 2

RE[5]: Qt
by Moochman on Tue 14th Aug 2007 01:04 UTC in reply to "RE[4]: Qt"
Moochman Member since:
2005-07-06

It is unfortunately a common misinterpretation that some technology, be it Qt or C++, would be *required*, while it is basically just *extraordinary convenient*

Perhaps a better way of putting this would be, "while it is just extraordinarily inconvenient to develop for KDE using any other toolkit."

Edited 2007-08-14 01:04

Reply Score: 3

RE[6]: Qt
by anda_skoa on Tue 14th Aug 2007 12:05 UTC in reply to "RE[5]: Qt"
anda_skoa Member since:
2005-07-07

Perhaps a better way of putting this would be, "while it is just extraordinarily inconvenient to develop for KDE using any other toolkit."


No. The convenience of one option does not imply the inconvenience of another.

Take for example any toolkit, which surely offers more convenience than using xlib directly. This does not exclude the likeliness that any other toolkit is also offering convenience over directly using xlib.

Reply Score: 3

RE[7]: Qt
by Moochman on Thu 16th Aug 2007 02:24 UTC in reply to "RE[6]: Qt"
Moochman Member since:
2005-07-06

I'm not talking about xlib, or any other imaginary "convenience implying inconvenience", I'm talking about the real-world case of Qt vs other toolkits to develop KDE apps. That's all.

Reply Score: 2

RE[5]: Qt
by Lobotomik on Tue 14th Aug 2007 07:06 UTC in reply to "RE[4]: Qt"
Lobotomik Member since:
2006-01-03

Stuff like wxWindows is where Trolltech's model blows it.

There are wxWindows bindings for Win32, OSX, GTK+, X11, Motif, WinCE. However they cannot exist for Qt without incurring in Trolltech's wrath, because a path to bypass Trolltech's per-developer-seat licensing would appear.

Same with Java's SWT: It nicely uses native GTK, but a Qt version is not possible. If you want Java and Qt, you have to use Trolltech's new java bindings, which must surely be great but hardly mainstream.

I suppose Mono would run into the same wall.

Now, think about the position of vendors with a software platform, like Motorola, Palm, Access or Intel. Should they choose a widget set which any developer may use for open or proprietary code, from any programming language and whatever abstraction layer they wanted? Or would they have to tell their customers that a third party called Trolltech was somewhat involved in the deal, who wanted 2600 per programmer for Qt, plus a further 1400 for the Jambi Java libraries (about $3500 and $1800), and who would further impose limitations on what abstraction layers may be used?

It may so be that Qt is superior to GTK, but evidently not superior enough to overcome this shortcomings, as the recent history in the emergence of Linux-based software platforms for embedded devices and cellphones clearly shows.

Reply Score: 3

RE[6]: Qt
by anda_skoa on Tue 14th Aug 2007 12:19 UTC in reply to "RE[5]: Qt"
anda_skoa Member since:
2005-07-07

However they cannot exist for Qt without incurring in Trolltech's wrath, because a path to bypass Trolltech's per-developer-seat licensing would appear.


No, this is a common mistake when considering Qt's licences.
wxWidgets's licence can be used with either the Qt's GPL or Qt's QPL in an open source implementation of, say, wxKDE.

There is no bypassing, because the application developers are using wxWidget's API, not Qt's. Obviously if they would ship wxKDE as part of their product, they would have to comply to one of the three Qt licences.

However, if they do not ship is as a part of the product but have made sure it can be used with any of the available wxWidgets implementations, it would be the user's or administrator's choice to have it use the KDE base implementation on KDE based systems.

Same with Java's SWT: It nicely uses native GTK, but a Qt version is not possible.


Right, same mistake as above. A bit more complex since the licence of SWT somehow conflicts with the GPL, however I have yet to see any clause in the QPL which block, say, a BSD licenced SWT implementation on top of Qt.
In the special case of SWT, there have been statements by Trolltech people that they are looking into including SWT's licence in the newly added exceptions to Qt's GPL licence option.

As I said, there are common misinterpretations regarding Qt and KDE and related development options, often repeated in faith of the original source's knowledge of the situation.

Having a closer look on either technical or legal aspects of the technology in question usually enables to see where the original source missed some detail or based conclusions on wrong assumtions

Reply Score: 3

RE[6]: Qt
by segedunum on Tue 14th Aug 2007 17:47 UTC in reply to "RE[5]: Qt"
segedunum Member since:
2005-07-06

Stuff like wxWindows is where Trolltech's model blows it.

I'm sorry, but no one gives a shit about wxWindows and few people use it. Why bother binding an inferior bit of technology on? I don't see it affecting anyone at all, and I don't see people hammering on the gates shouting "We need wxWindows bindings or nothing will work!"

Same with Java's SWT: It nicely uses native GTK, but a Qt version is not possible.

It is technically possible under the QPL, but many people don't want to do it for reasons that are best known to them.

Now, think about the position of vendors with a software platform, like Motorola, Palm, Access or Intel. Should they choose a widget set which any developer may use for open or proprietary code, from any programming language and whatever abstraction layer they wanted?

If you're talking about 'free' proprietary development, no such widget set exists that meets that criteria of anything approaching credible quality.

Or would they have to tell their customers that a third party called Trolltech was somewhat involved in the deal...

On an open source platform such as Linux where a company has chosen to use Qt as the basis for development, they can provide options where they can use Qt and pay Trolltech or they can provide other options that already exist. It sill wouldn't stop developers doing J2ME only development and getting it to run.

and who would further impose limitations on what abstraction layers may be used?

And where do you get that from?

It may so be that Qt is superior to GTK, but evidently not superior enough to overcome this shortcomings

The problem is that GTK is either good enough to work with to do all this stuff, or it isn't, and Nokia have come out and said that it isn't. Skirt around this all you like, but investment has to go into the platform somewhere.

...as the recent history in the emergence of Linux-based software platforms for embedded devices and cellphones clearly shows.

If you think that GTK is big on cellphones and embedded devices, you need to get out more.

Reply Score: 3

RE[4]: Qt
by segedunum on Mon 13th Aug 2007 21:36 UTC in reply to "RE[3]: Qt"
segedunum Member since:
2005-07-06

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

I'm assuming you mean Qt there. Well, they managed to integrate GTK into the look and feel of KDE, and it's only the motivation to do it from GTK itself that is holding back GTK from having better integration with KDE.

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.

That's because no one has written those alternatives yet, there isn't the motivation and there isn't the market. Doesn't mean that it couldn't be done.

Not only that, there are many *zero-cost* development options for Windows.

I like 'zero cost' and Windows in the same sentence.

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...

KDE doesn't require you to do anything at all, and it's not like we're talking about proprietary software here that enforces Qt at all. Alternatives can certainly be written.

It is pretty sad when there is more competition in development tool providers in the Windows world than there is in the KDE world.

That's because there is a bigger market.

Due to KDE's choice of Qt as their toolkit, developers are limited to chosing from a single vendor for their platform development needs

As popularity and demand grows, so will the alternatives.

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...

Well, that's not true, but given that scenario, commercial developers have certainly never complained before, and they haven't complained too much about the requirement to fork out for Windows to develop Windows applications.

Reply Score: 4

RE[5]: Qt
by binarycrusader on Mon 13th Aug 2007 23:04 UTC in reply to "RE[4]: Qt"
binarycrusader Member since:
2005-07-06


Well, that's not true, but given that scenario, commercial developers have certainly never complained before, and they haven't complained too much about the requirement to fork out for Windows to develop Windows applications.


Which is an irrelevant argument. We're talking about development tools, not the platform itself. Not only that, you pay for Windows once for years and use it, you don't pay for it every year per-developer (user) unlike Qt.

To use Windows programs, a user must have Windows. The point is that if the user has KDE, they already have the platform, but must pay additional costs to develop proprietary commercial applications for it. In the Windows world, once you have the platform installed, you pay no additional costs to develop proprietary applications for it. The same is true of OS X, etc.

Not only that, let's say that I buy a *supported* installation of Ubuntu, that's a few hundred dollars I paid. Now I have to paid a few thousand to develop proprietary applications for KDE.

In comparison, I can buy an OEM copy of Windows for USD150 or less, and develop proprietary applications for free.

Reply Score: 3

RE[6]: Qt
by segedunum on Tue 14th Aug 2007 00:14 UTC in reply to "RE[5]: Qt"
segedunum Member since:
2005-07-06

Which is an irrelevant argument. We're talking about development tools, not the platform itself.

As a developer, I'd rather pay for something that is going to make me money personally, and have a general purpose platform and installed base that is virtually free for everyone to use. If KDE can be that quality platform built off the back of solid development tools then we've got half a chance of actually seeing desktop Linux happen.

Not only that, you pay for Windows once for years and use it, you don't pay for it every year per-developer (user) unlike Qt.

You don't pay for Qt per year unless you want to. Per year is for support and stuff like the newsletter. It doesn't stop you using Qt.

The point is that if the user has KDE, they already have the platform, but must pay additional costs to develop proprietary commercial applications for it.

No, because there is no reason whatsoever that other alternatives will not become available as KDE as a platform grows in popularity. KDE and Qt exists in an open source environment that enables this to happen.

In the Windows world, once you have the platform installed, you pay no additional costs to develop proprietary applications for it. The same is true of OS X, etc.

Software vendors developing for Windows and OS X fork out an absolute ton of money for toolkits, components and development tools. This simplistic, and quite frankly, non real world view of things doesn't seem to have any relevance for them whatsoever.

Software vendors in the Windows world will take one look at GTK and Gnome development and ask themselves "Right, where are the commercial development tools that will actually make this thing work for me?" That's the way ISVs work, and very few people who start talking immediately about license fees understand that.

You're stirring around trying to find something of any relevance whatsoever to your average software vendor here, but there just isn't.

Reply Score: 5

RE[7]: Qt
by binarycrusader on Tue 14th Aug 2007 02:47 UTC in reply to "RE[6]: Qt"
binarycrusader Member since:
2005-07-06

No, because there is no reason whatsoever that other alternatives will not become available as KDE as a platform grows in popularity. KDE and Qt exists in an open source environment that enables this to happen.


Which is completely irrelevant because those alternatives do not yet exist. As I said before, I have no problem with Trolltech themselves as a commercial software developer (my profession). My problem is with KDE's platform choices.

Software vendors developing for Windows and OS X fork out an absolute ton of money for toolkits, components and development tools. This simplistic, and quite frankly, non real world view of things doesn't seem to have any relevance for them whatsoever.

I don't know why you believe that, but it is totally incorrect. Many commercial software developers (especially small, independent ones) don't pay a dime for their development tools. I certainly don't.

Especially on the OS X platform. There was a time when your belief is true, but since OS X debuted, the Xcode and various other suites have helped span a myriad of indpendent software developers that don't pay Apple a dime to develop their applications (unless they *want* an ADC membership, which is not required).

Also, Microsoft finally realised as of last year that they needed something like visual studio express edition which allows commercial development with some very nice tools.

Edited 2007-08-14 02:50

Reply Score: 2

RE: Qt
by anda_skoa on Sun 12th Aug 2007 20:08 UTC in reply to "Qt"
anda_skoa Member since:
2005-07-07

I don't know why no big enterprise like IBM, Sun or even Nokia until now simply didn't buy Trolltech...


I think it is more a question of Trolltech not wanting to sell.

Since the company is large owned by its founders and employees, it cannot or not easily be bought "by force".

And not everyone fancies being bought by some mega corporation, because this likely means loosing control of making development decisions or at least having to go through layers and layers of management.

I am also quite sure that the current customer base likes they it is now, since a smaller company is more likely to listen to their customers' needs than a mere department of a big company.

Reply Score: 5

RE: Qt
by butters on Sun 12th Aug 2007 20:17 UTC in reply to "Qt"
butters Member since:
2005-07-08

Nobody wants Nokia to buy Trolltech. That would be a disaster. I can't see Steve Mills finding a use for Qt in IBM's SOA/SAAS/AJAX strategy. Sun isn't known for their C++ prowess, but they might be interested in Qt Jambi.

The new GPL exceptions for Qt allow a lot more licenses to link to Qt under the GPL. For example, ISVs can use the Apache and never distribute a single line of source code. It would be hard to charge a simple fee since the binaries can be redistributed, but what ISV really sells software anymore? If it's binary only, there's practically no limit to how you can exploit your users for profit. Limited trials, integrated advertising, subscription requirements, you name it.

Reply Score: 4

RE: Qt
by segedunum on Sun 12th Aug 2007 20:51 UTC in reply to "Qt"
segedunum Member since:
2005-07-06

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).

Because it would be a disaster. Qt is as good as it is because it has a company behind it that has a good business model behind it and is solvent, who can then have the motivation and see the need to continually improve it and ensure their future survival.

GTK, sadly, just does not have that kind of motivation behind it.

Reply Score: 8

RE: Qt
by ramunas on Sun 12th Aug 2007 21:38 UTC in reply to "Qt"
ramunas Member since:
2005-07-06


QT, specially Qt 4.x, is superior to GTK+ ...


Don't make bold claims. QT may be faster or slicker, but in my point of view as devoloper it's API is horid. It doesn't conform to C++ standards, it just hideos. But it's just my opinion, so as yours, don't make it universal truth.

Further more GTK+ was founded by community, it's main driving force is community, and not a company. This shows Nokia and others, that there will be interest in development of GTK+.

Reply Score: 2

RE[2]: Qt
by segedunum on Mon 13th Aug 2007 00:23 UTC in reply to "RE: Qt"
segedunum Member since:
2005-07-06

Don't make bold claims. QT may be faster or slicker, but in my point of view as devoloper it's API is horid. It doesn't conform to C++ standards, it just hideos.

The C++ standards, such that they are, are horrendous themselves! That's why Qt attempts to improve on C++ by giving you stuff like foreach etc. No one likes standard C++, and that's why C++ has such a bad reputation.

You can't just claim that Qt is horrendous because it improves on things people don't like about C++ to start off with.

Further more GTK+ was founded by community, it's main driving force is community, and not a company. This shows Nokia and others, that there will be interest in development of GTK+.

Well, from the article it seems that Nokia are complaining about the lack of interest in development of GTK. There's no GTK 3 on the horizon.

Reply Score: 5

RE[3]: Qt
by ramunas on Mon 13th Aug 2007 07:41 UTC in reply to "RE[2]: Qt"
ramunas Member since:
2005-07-06


The C++ standards, such that they are, are horrendous themselves! That's why Qt attempts to improve on C++ by giving you stuff like foreach etc. No one likes standard C++, and that's why C++ has such a bad reputation.


STL already has foreach which is more general than QTs, so it's not an improvement over the standard.

C++ has bad reputation for its terribly hard semantics and complex syntax. QT isn't improving in this respect, because they use the same language.

If you want to see how decent C++ toolkit API looks like take a look at GTKmm.

Reply Score: 2

RE[4]: Qt
by _LH_ on Mon 13th Aug 2007 07:56 UTC in reply to "RE[3]: Qt"
_LH_ Member since:
2005-07-20

Qt4 is pretty nice as it doesn't rely on macros like Qt3 did and I really can't see any major difference on using object-oriented stl vs. Qt.

Reply Score: 2

RE[4]: Qt
by superstoned on Mon 13th Aug 2007 09:09 UTC in reply to "RE[3]: Qt"
superstoned Member since:
2005-07-07

Lovely!!!

If you want to see how decent C++ toolkit API looks like take a look at GTKmm.

This is the first time I heard anyone dare to refer to GTKmm in a positive way, lol... It's generally used as an example of a horrible language binding ;)

Reply Score: 6

RE[4]: Qt
by leos on Mon 13th Aug 2007 15:26 UTC in reply to "RE[3]: Qt"
leos Member since:
2005-09-21

STL already has foreach which is more general than QTs, so it's not an improvement over the standard.


Yes there is a foreach, and it's a huge pain in the ass to use. You supply your iterator and a function to call for each item. So instead of a nice logical syntax like

foreach(QGraphicsItem* item, selectedItems())
item->setSelected(false);

you get

for_each(selectedItems().begin(), selectedItems().end(), &unselectItem);

void MyClass::unselectItem(QGraphicsItem* item) {
item->setSelected(false);
}

So tell me, which one of these is more convenient to use? That's what I like about Qt. The API is designed to make it logical and convenient to use, given the most common use case. 99% of the time, when I think of what I want to do, Qt supports it, in exactly the words I was thinking of describing the feature.

Reply Score: 5

QT Embedded runs well on N770
by IkeKrull on Sun 12th Aug 2007 22:32 UTC
IkeKrull
Member since:
2006-01-24

I ported a QT Embedded app to the Nokia 770, and it was pretty simple - just needed to add a basic touchscreen driver to QTE using the input device events the screen throws, and either disable the 'update only when told' mode of the lcd controller, or add a 'repaint' ioctl to the QT graphics layer.

It wouldn't be difficult for Nokia or anyone else to switch from GTK+ to Qt from a platform point of view (Of course, the apps themselves would need to be recoded which represents significant effort), and I personally feel Qt represents a far better API. GTK+, in my experience, is very slow and resource-hungry, especially when it has to be run on top of X11.

I'm personally at the point where I see a very uncertain future for GTK+ - I would never choose to write another GTK application where Qt was an option, and i certainly wouldn't go back to GNOME from KDE.

Licensing is the major sticking point i guess, with LGPL seen as being GTK's major benefit over Qt's GPL - Which I understand completely, although I have to wonder just how big an issue this really is for either purely commercial developers or purely OSS developers.

As someone who has not been following GTK+ development very closely, if Trolltech offered an LGPL Qt, what major advantages would GTK+/GNOME be left with?

Reply Score: 9

what situation?
by elanthis on Mon 13th Aug 2007 03:59 UTC
elanthis
Member since:
2007-02-17

Not only that, the C++ ABI situation on Linux is absolutely horrid.


Dude, welcome to 2007. No, scratch that, welcome to 2002. There is no "horrid ABI situation" with C++ on Linux.

Reply Score: 3

RE: what situation?
by draethus on Mon 13th Aug 2007 05:51 UTC in reply to "what situation?"
draethus Member since:
2006-08-02

Dude, welcome to 2007. No, scratch that, welcome to 2002. There is no "horrid ABI situation" with C++ on Linux.

Even in the latest version of libstdc++, you can't give symbol versions to templates, which means mixing different versions of libstdc++ leads to segfaults and memory corruption (and different packages even on the same distro can use different libstdc++ versions, so your software will work in some cases and break in others). See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405 and http://trac.autopackage.org/wiki/LinuxProblems.

Reply Score: 4

RE: what situation?
by binarycrusader on Mon 13th Aug 2007 13:06 UTC in reply to "what situation?"
binarycrusader Member since:
2005-07-06

Dude, welcome to 2007. No, scratch that, welcome to 2002. There is no "horrid ABI situation" with C++ on Linux.

Bzzzt. Wrong.

Show me where the C++ ABI standard is for Linux.

Show me where there is a gurantee that it won't change with the next version of libstdc++, or for at least the next few years.

Show me how I can build a binary application that will work on all Linux distributions made since 2005 up to 2007 without issue.

Oh wait, you can't.

That's my point.

The problem with the C++ Linux ABI (which is really the GNU C++ ABI) is that it changes frequently.

This means every year I hear that the "C++ ABI problems are solved!" and every year I encounter problems that were supposedly solved last time.

Edited 2007-08-13 13:07

Reply Score: 3

RE[2]: what situation?
by yokem55 on Mon 13th Aug 2007 13:55 UTC in reply to "RE: what situation?"
yokem55 Member since:
2005-07-06

The problem with the C++ Linux ABI (which is really the GNU C++ ABI) is that it changes frequently.


I am no developer, but I do run gentoo, and I know when the c++ abi changes due to a gcc upgrade (I have to rebuild everying linking against libstdc++), and if I remember correctly, there hasn't been an abi breakage since the upgrade from gcc-3.3 to 3.4, and 3.4 was shipped in April of 2004. So, comparitively with the previous abi history of gcc (about 1 break per year), things have stablized considerably in C++ abi land with gcc 3.4+.

Reply Score: 4

RE[3]: what situation?
by binarycrusader on Mon 13th Aug 2007 19:16 UTC in reply to "RE[2]: what situation?"
binarycrusader Member since:
2005-07-06

"The problem with the C++ Linux ABI (which is really the GNU C++ ABI) is that it changes frequently.


I am no developer, but I do run gentoo, and I know when the c++ abi changes due to a gcc upgrade (I have to rebuild everying linking against libstdc++), and if I remember correctly, there hasn't been an abi breakage since the upgrade from gcc-3.3 to 3.4, and 3.4 was shipped in April of 2004. So, comparitively with the previous abi history of gcc (about 1 break per year), things have stablized considerably in C++ abi land with gcc 3.4+.
"

Wrong, the ABI recently chnaged again in 4.1:
http://gcc.gnu.org/gcc-4.1/changes.html

Reply Score: 2

RE[4]: what situation?
by yokem55 on Mon 13th Aug 2007 21:22 UTC in reply to "RE[3]: what situation?"
yokem55 Member since:
2005-07-06

From the page you linked:

The x86-64 medium model (that allows building applications whose data segment exceeds 4GB) was redesigned to match latest ABI draft. New implementation split large datastructures into separate segment improving performance of accesses to small datastructures and also allows linking of small model libraries into medium model programs as long as the libraries are not accessing the large datastructures directly. Medium model is also supported in position independent code now.

The ABI change results in partial incompatibility among medium model objects. Linking medium model libraries (or objects) compiled with new compiler into medium model program compiled with older will likely result in exceeding ranges of relocations.


Basically, this is only a partial abi breakage on 64-bit binaries with data segments that can exceed 4 GB. Anything that is 32-bit only (as is the vast majority of ISV-ware) is unaffected.

Edited 2007-08-13 21:23

Reply Score: 1

RE[5]: what situation?
by binarycrusader on Mon 13th Aug 2007 22:58 UTC in reply to "RE[4]: what situation?"
binarycrusader Member since:
2005-07-06

Basically, this is only a partial abi breakage on 64-bit binaries with data segments that can exceed 4 GB. Anything that is 32-bit only (as is the vast majority of ISV-ware) is unaffected.


The point is, the ABI keeps changing. Even partial breakage is still breakage.

It only adds to the frustration of developers using the platform.

Reply Score: 2

RE[6]: what situation?
by yokem55 on Tue 14th Aug 2007 04:19 UTC in reply to "RE[5]: what situation?"
yokem55 Member since:
2005-07-06

It only adds to the frustration of developers using the platform.


How can this particular ABI breakage cause frustration for the average ISV dev on the gnu c++ platform? If a developer is only targeting 32-bit x86 (which until 64 bit linux becomes far more widespread, this is going to be the vast majority of ISV's) this particular ABI change will have ZERO impact, and the ABI is exactly the same as it was in gcc 4.0 and 3.4.

Reply Score: 2

RE[7]: what situation?
by binarycrusader on Tue 14th Aug 2007 13:14 UTC in reply to "RE[6]: what situation?"
binarycrusader Member since:
2005-07-06


How can this particular ABI breakage cause frustration for the average ISV dev on the gnu c++ platform?


See, now you're qualifying it. You're trying to "wiggle out" of the point that there are ABI changes. First your claim was that there were no ABI changes, then your claim was only for a certain platform, and now your claim is that it doesn't affect the average (whatever that is) isv. You keep narrowing the scope of your claims.

Remember, the whole discussion was regarding my point that the ABI keeps changing. I don't care what part of the ABI does change. ABI changes are difficult, annoying, and should have been unnecessary with the proper foresight and planning on the part of the gcc team. Many other platforms have managed to maintain their ABI decades without issue. Only the GNU platform seems to manage to screw it up every year.

Reply Score: 2

RE[2]: what situation?
by leos on Mon 13th Aug 2007 15:45 UTC in reply to "RE: what situation?"
leos Member since:
2005-09-21

Show me how I can build a binary application that will work on all Linux distributions made since 2005 up to 2007 without issue.


Well apparently every proprietary software developer using Qt on linux has figured it out. As someone else already pointed out, there hasn't been a breakage for a long time (~2004), so just building it normally should accomplish what you want.

Reply Score: 5

RE[3]: what situation?
by binarycrusader on Mon 13th Aug 2007 19:15 UTC in reply to "RE[2]: what situation?"
binarycrusader Member since:
2005-07-06

"Show me how I can build a binary application that will work on all Linux distributions made since 2005 up to 2007 without issue.


Well apparently every proprietary software developer using Qt on linux has figured it out. As someone else already pointed out, there hasn't been a breakage for a long time (~2004), so just building it normally should accomplish what you want.
"

Wrong again.

See the recent GCC 4.1 release:
http://gcc.gnu.org/gcc-4.1/changes.html

Also, note that I specifically stated that I wanted to build an application that worked on distributions made since 2005. There have been at least three ABI changes since 2005.

Reply Score: 2

Let's be cool
by pecisk on Wed 15th Aug 2007 20:31 UTC
pecisk
Member since:
2005-10-20

Yeah, what would be article about 10 years of GNOME without solid flamewar about advantages/disavantages/honesty/dishonesty/etc/atnauseum each toolkit.

People, get a grip! Nor GTK, nor QT won't go away. Bashing oponents for being knee-jerking, less free than another one, less user friendly in this scenario is utter nonsense, because both enviroments have proven to be very useful for number of people!

But looking from other side, there is a reason why GTK and GNOME is still mostly chosen as business platform, while QT is beloved by "I will never forget Windows" and geeks crowd. GNOME has striking simplicity and elegance, but KDE has power user karma all over it - partly thanks to toolkit it was based upon. Yes, there are GNOME apps who are "sea of options" in their menus and there are KDE who are very lightweight and simple.

Some people say it confuses ISV and it blocks acceptance of Linux as platform. Right, don't get me started. It was never a problem for Windows, which usually hosts myriads of apps based on very different toolkits. ISV is usually driven by money and they watch what is available for them and how they can use it. For long time QT was king, because of superior documentation and leadership from Trolltech. GTK and GNOME was cool, but rarely anyone knew what to do with them. Situation for now has changed - GNOME has good docs (although project still working on improving them), good, stable API and documented coding practices. Also lot of new, interesting technologies have found their home first at GNOME project - DBUS, NetworkManager, Compiz/Beryl, Tango project's initialization was driven by GNOME, etc.
But now KDE tries to turn the tide with KDE4. And God, this is exciting times because of that. Both projects COMPETE. And as we see, competition is about to change GUI very radically.

So let's be cool. We have it! We all have our favorite environments. It rocks, because they are suited for us. So let's celebrate that!

Reply Score: 1