Submitted by “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.”
Second one fron GUADEC.
I don’t know much about derStandard.at but juding from these two interviews, they have some good reporters.
They’re definitely one of the better Austrian newspapers.
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?
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’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.
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.
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.
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).
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
“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.
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.
That’s a good metric. Do you have any research to support the position that Qt is better than GTK+ in this area?
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.
Smaller development community? Far fewer paid developers? Do you have any data to back that up? Trolltech alone employs more than 200 people.
It’s true that more people work on KDE, but that’s because KDE has a larger community of people developing in their free time. Gnome has more paid developers (a research study has been done into that, some time ago).
And indeed, Trolltech employs a lot of people on Qt. Of course, they don’t just work for KDE, but mostly for their clients, like the movie studio’s…
Anyway, about your call for ‘numbers’ -> feel free to generate them. According to many developers, it takes around 1/4 less code to write a Qt/KDE app than an equivalent GTK/Gnome app. go ahead and try to write a multimedia app with KDE 4 beta 1…
URL please. Otherwise, I’m going to assume that you’re making this up. I’ve asked you several times to provide some hard facts, but you keep repeating yourself.
Of course they don’t all work directly on KDE, but nonetheless Trolltech has 200 people working on Qt and related products, and Qt is the largest and most important part of KDE.
You’re the one making these outrageous claims, and now you’re asking me to verify them and do your research for you? If you’re under the impression that multimedia development with GTK/GNOME is difficult, I advise you to look into the gstreamer python bindings.
URL please. Otherwise, I’m going to assume that you’re making this up. I’ve asked you several times to provide some hard facts, but you keep repeating yourself.
I’d love to give you an url, but this is simply from what I’ve heard from those who did talk to this researcher.
You’re the one making these outrageous claims, and now you’re asking me to verify them and do your research for you?
I’m not making outrageous claims, I’m merely parroting what many developers say and write.
And as I said, it’s silly to ask for numbers proving anything is easier or harder for developers – it’s way too subjective.
Again, GTK is to Qt what Gecko is to KHTML/webkit. Now I’m sure some will argue Gecko is easier to hack on than Webkit. But most people would describe working on Webkit as comparable to going to far with SM.
If you’re under the impression that multimedia development with GTK/GNOME is difficult, I advise you to look into the gstreamer python bindings.
One bird (which one was it? its zwaluw in dutch, but swallow can’t be right, can it?) doesn’t make summer. I’m sure there is a lot of GTK/Gnome stuff which is better than their comparable Qt/KDE equivalent.
BTW I’m not going to respond anymore. I don’t have ‘numbers backing my statements’ (and the why I described), and besides – I’m no developer, so you should talk to people fluent in both GTK and Qt, and without a ‘religion’ in the area of language (C/C++) or toolkits. All of those ppl I have spoken to where very clear on their preference, but why should you believe me? Try a meeting like FOSDEM to ask some hackers…
Just for the fun of it I grabbed Amarok2 (the kde4 version of Amarok as far as I could tell) and Rhythmbox. I ran sloccount over them both. Amarok2 came out with 190k and Rhythmbox came out with 100k. So that comes out with half the code in the opposite direction you claimed one quarter.
Now, I can hear you say, “But Amarok has far more functionality than Rhythmbox.” That may be true, but does it have 8 times (this number comes from the actual sloc and your 1/4 estimate) the functionality of Rhythmbox? I don’t think so. From a quick read Amarok also contains a media engine, I believe its called Phonon. Well, Rhythmbox happily uses gstreamer. So I don’t think you can count that against it.
In summary, I call BS on your 1/4 estimate. It seems unrealistic for any nontrivial application. I think that this will become even better highlighted when you compare qt4/c++ versus gtk/python or ruby or mono or Java or Perl. Or for that matter even gtkmm. GTK has its warts, but IMO so does QT. In fact, one of QT’s biggest warts seems to be its lilliputian community that seems to need to put down Gnome/Gtk at every opportunity. I think they are probably about equivalent in their expressiveness and thats what really matters in the end. The rest can and will likely be fixed.
“I don’t think so. From a quick read Amarok also contains a media engine, I believe its called Phonon. Well, Rhythmbox happily uses gstreamer. So I don’t think you can count that against it. ”
One correction: amaroK does not contain a “media engine”: kdelibs contains Phonon, which is a lightweight wrapper around existing media engines (e.g. gstreamer, xine, etc) that will be used by most KDE4 apps, including amaroK.
Indeed. The version of Amarok he tested doesn’t use Phonon, instead it contains at least 4 multimedia engines, besides supporting both SQL-lite and MySQL. In KDE 4, those will all be removed in favor of using Phonon and Strigi (the latter is most likely a more longterm thing). Thus reducing the SLOC heavily.
ehm, actually, I’m not sure about what I said, I think Amarok might already use Phonon. Not strigi, though. BTW he should’ve compared Juk and Rythmbox, those are much more comparable in terms of features.
And I should add that with 1/4th I meant 25% LESS, not 75%. And of course, this all provided the app actually USES the infrastructure provided by the toolkit/framework.
First of all, the grandparent claimed 1/4 LESS code, not 1/4 OF the code. Please pay attention.
Also, Amarok 2 is not a good one to compare, since it is still in heavy development and will have a lot of code that may not be included in the final version (lots of ideas being tried out right now).
So from the code size differences, Amarok should have 2.5 times the features of rythymbox (not 8 times, this is due to your mistake above). I wouldn’t be surprised if this was true. Amarok allows output to Gstreamer, Xine, and helix engines, has different UIs to chose from, has plugin support in different languages, extensive context information features (lyrics, wikipedia, statistics), etc.
Overall, comparing the two projects is a silly endeavour, since they are so different. You could only compare them if one was a direct port of the other.
He problably meant “technically”
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.
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.
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.
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
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.
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.
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
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?
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.
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…
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.
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.
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 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”.
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
Yup, last I heard most of their UI is their own toolkit. Some things like menus and printing support uses Qt.
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.
Actually, Adobe used Qt to make Photoshop Elements and Album, IIRC.
Yeah, but they used GTK+ for Reader.
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
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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
I don’t have a lot of experience at different places yet, but what you’re describing doesn’t really match my experience so far. We have about 10 developers (some part time) and all of us have copies of Visual Studio. I can’t imagine doing my current job without it. We also have 5 MSDN subscriptions which are a heck of a lot more expensive than QT licenses. In fact, I think they’re wasting money on them but apparently they don’t care.
Technically we could do our developement in notepad without any support from MS, but I think most people actually developing would tell you that is a very bad idea.
Which is completely irrelevant because those alternatives do not yet exist.
Those options can certainly exist, which is the whole point. There needs to be a market first for it though.
My problem is with KDE’s platform choices.
I’m afraid KDE’s platform choices are spot on. Qt has provided a great fundamental and solid architecture to build KDE on, and that’s what people want – a quality open source desktop. When developers start going for that platform, they want good development tools and APIs. As popularity grows, so does the demand and need for alternative development paths, and that can be done.
A desktop that has based its philosophy on developing absolutely everything for nothing is just not going to have the infrastructure to take us forward sadly.
I know you’re a little upset, but people want quality from a Linux desktop, not some philosophy that has little relation to the real world. As a company, Trolltech will probably reap the benefits of helping KDE as much as possible, when they could easily have thrown the towel in at various points. As demand grows for alternatives and competition, that will happen.
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.
Then I’m afraid you’re in the minority and you’re almost certainly running around fixing things and spending a ton of time and money on other things you don’t need to. Yes, even small, independent companies pay for development tools, shock horror.
It’s the sort of software-written-in-a-basement argument you get from an awful lot of people who really don’t know how to run a software business.
Read smitty’s comment about his business having a lot of MSDN subscriptions – some of which they may not need. That’s the way software development businesses work.
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).
Hmmmm. I take it they pay for OS X, and they pay to have OS X upgraded at every release?
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.
Visual Studio Express is deliberately so inadequate for developers that it becomes necessary to purchase Visual Studio anyway.
Edited 2007-08-14 11:53
Visual Studio Express is deliberately so inadequate for developers that it becomes necessary to purchase Visual Studio anyway.
That is an opinion. I think you’ll find a very alive, vibrant community using those tools that are supposedly “inadequate.”
In fact, if you consider those tools inadequate, I would like to introduce you to Linux circa 1995 when many developers (such as myself) started developing for Linux. You want to talk about inadequate tools, we’ll start there.
The point is that the tools you talk about are a convenience, not a requirement.
You can try to argue this any way you like, but these are the facts that remain:
* Windows does NOT require developers to pay licensing fees to develop proprietary (free or commercial) applications.
* OS X does NOT require developers to pay licensing fees to develop proprietary (free or commercial)
* OS license costs are irrelevant since these are often already paid for with the purchase of a system, or are necessary to use the applications of a platform anyway. Additionally, all users have to have a license regardless of whether they do development. Hence, it is non-discriminatory.
* The KDE platform is discriminatory since the platform is free for users, but costs money for developers since they must license Qt to perform proprietary, truly integrated development.
* Development tools such as Visual Studio retail edition, etc. are not required, but merely conveniences for development. The GNU/Linux platform and others didn’t have equivalent tools for years, yet software developers such as myself and millions of others have managed just fine.
If you wish to dispute the above points, and the above points only, feel free to reply with *facts* and links supporting your claims.
That is an opinion. I think you’ll find a very alive, vibrant community using those tools that are supposedly “inadequate.”
Have a look at Microsoft’s recent efforts to get a guy shut down because he provided a plugin for Visual Studio Express, and turned plugins on. Microsoft has deliberately disabled plugins in VSE because they don’t want people using it for anything other than hobbyist stuff:
http://www.channelregister.co.uk/2007/06/06/microsoft_mvp_threats/c…
I don’t call that vibrant.
Windows does NOT require developers to pay licensing fees to develop proprietary (free or commercial) applications.
The do require you to have Windows licenses, and at times, Microsoft Office and its components installed depending on what the ISV hooks into, as do their customers.
OS X does NOT require developers to pay licensing fees to develop proprietary (free or commercial)
But developers do have to pay for OS X and pay to have it upgraded, as do their customers.
Windows and OS X are not free platforms.
OS license costs are irrelevant since these are often already paid for with the purchase of a system, or are necessary to use the applications of a platform anyway.
It’s still a big cost. Go and ask your average software development company just how many Windows machines, and different versions of Windows, they have to test their software on.
Additionally, all users have to have a license regardless of whether they do development. Hence, it is non-discriminatory.
That’s as discriminatory as it gets! Since developers are the ones making the money, then they should be paying. Users and business have to pay for a platform, and in some cases an office suite, just because that’s what developers have written for.
The KDE platform is discriminatory since the platform is free for users, but costs money for developers since they must license Qt to perform proprietary, truly integrated development.
Yadda, yadda, yadda. You can repeat that as often as you like, but users do not care (they want a quality desktop), developers do not care (they want tools to sell software and make money), and it is only the people who naively think that this is what matters most to people that are whinging.
Development tools such as Visual Studio retail edition, etc. are not required, but merely conveniences for development.
Software development companies seem to think that they do matter, and Microsoft gears development as much towards the full versions of Visual Studio as possible.
In summary: Telling people “Oh, you don’t have to pay any money to do development” is not a valid reason to use a platform or a toolkit. It doesn’t seem to have stopped Nokia complaining about the progress and lack of fit-for-purpose of GTK.
Edited 2007-08-14 17:30
Irrelevant. I never said perfect community. I said vibrant. Big difference.
Whoop tee do, as I mentioned before, all *users* have to have Windows licenses and those costs are one-time.
The same as any other software. Irrelevant.
Which is irrelevant to this discussion. We are talking about development tools, NOT operating systems.
Which again is irrelevant. Over 90% of the world’s desktop users have Windows. So the cost of a Windows license is irrelevant.
That’s an interesting view, but not a factual one.
Regardless of what some think, the point is that they are not factually required.
Yes it is for some people. It is for me, and many others. It is why I will likely never write a commercial applications for KDE and why I will continue to support Gtk, Windows, and OS X.
Irrelevant. I never said perfect community. I said vibrant. Big difference.
That’s not a response I’m afraid. What’s clear is that Microsoft does not want you using VSE when you could be using VS. It’s their platform, and you play by their rules, and theirs alone.
Microsoft own and control the OS, the platform and the development tools, and you’re complaining about Trolltech creating an open sourced toolkit used to create an open source desktop, not created or controlled by Trolltech, running on an open source operating system, again, not owned or controlled by Trolltech?!
I think you’ve lost some marbles somewhere.
Whoop tee do, as I mentioned before, all *users* have to have Windows licenses and those costs are one-time.
So users pay for additional software and all that entails (security issues etc.), in addition to your own? Not the way forward I’m afraid.
Developers also have to pay for the software they need to develop, so we still have costs here.
The same as any other software. Irrelevant.
Not irrelevant I’m afraid. You’re complaining about developers paying for software, but OS X and Windows are not free platforms for users or developers!
The operating system you need to develop on is a cost, whatever way you cut it.
Which is irrelevant to this discussion. We are talking about development tools, NOT operating systems.
Hair splitting in order to get around something that is staring you in the face.
Developers need an operating system to develop software on, and if that’s proprietary, it has to be paid for. Users need operating systems to run said software on. Why do you think free and open source operating systems and platforms are being developed?
Which again is irrelevant. Over 90% of the world’s desktop users have Windows. So the cost of a Windows license is irrelevant.
Wow. So Microsoft is a non-profit organisation, and all those Windows licenses are free? Wrong. The platform does have a cost, and especially to businesses, if they have a corporate license of some kind it really does cost.
Again, if you don’t know what you’re talking about, don’t comment.
That’s an interesting view, but not a factual one.
That’s because you live in a fantasy world. You walk through your business directory, look through the software they produce and their requirements and the real world looks quite a bit different.
Regardless of what some think, the point is that they are not factually required.
When you develop on Windows you play by Microsoft’s rules – you need their OS, their APIs, their .Net downloads and their development tools. End of story. Qt is not required to develop applications to run on KDE, simply because the platform that Qt and KDE builds on is not owned, nor controlled, by Trolltech. Yes, that GTK application will actually run in KDE, and it will actually fit in because of QtGTK.
If you don’t understand that then you don’t understand what open source software has been about – and it hasn’t been about allowing you to develop low quality software and wasting your time and money on firefighting so that you think that you’re developing for free.
Yes it is for some people. It is for me, and many others. It is why I will likely never write a commercial applications for KDE and why I will continue to support Gtk, Windows, and OS X.
Alas for you, you’re in a very small minority. Have a look through your business directory at ISVs, both large and small, do some networking (which I very much doubt that you do because you don’t know anyone developing software for a living) and find out what tools they use.
The development tools market, from components, to toolkits, to IDEs, to source control is absolutely huge. That isn’t the case because people want to develop for nothing. People see the need for good tools to help them, and that’s how they stay in business ;-).
*checks*, nope, they’re all still here
It is for some industries. I don’t see open source succeeding in the game industry, for example, anytime soon.
The point is, most users already have that OS platform whether they develop on it or not. Again, we are talking about development tools, the assumption is that the user likes to get things done and it is incredibly likely they already have Windows/OS X, etc.
You know, conditioner usually helps with split ends.
Well, my fantasy world pays lots of real money. If this is fantasy, I think I’d prefer to live in my fantasy world.
Fit in? Oh really. Fit in like Qt apps do on OS X? Sorry, but users can still tell when an app is not “truly native.”
Actually, I do. I have been developing software for a living for many years now. It pays quite well, and I love doing it. Programming is my passion. I have friends that work for major game developers, software companies, and other places. So, actually, I have quite a bit of experience with this. I even worked at a startup business for almost five years.
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.
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.
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.
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+.
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.
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.
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.
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
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.
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?
Dude, welcome to 2007. No, scratch that, welcome to 2002. There is no “horrid ABI situation” with C++ on Linux.
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.
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
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
From the page you linked:
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
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.
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.
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.
No my point is that the ABI change that you pointed out only going to affect a very narrow sub-set of developers. If you want to make a bigger deal of it than that, fine, that is your problem, but trying to make everyone think that your mole hill is a mountain isn’t going to get you anywhere.
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.
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!