Submitted by This is kind of… Well, good news, I suppose? It depends on where you allegiances lie, but it seems like Ubuntu is warming up to the idea of using Qt to develop applications. It’s no secret that Qt is a far more advanced development framework than Gtk+, so it only makes sense for Ubuntu – a GNOME/Gtk+ distribution – is looking at it.
The news comes from Matt Zimmerman, who writes about Qt on his blog. Speaking of keeping an open mind, he considers the possibility of using Qt on Ubuntu. “It is in this spirit that I have been thinking about Qt recently. We want to make it fast, easy and painless to develop applications for Ubuntu, and Qt is an option worth exploring for application developers,” he writes, “In thinking about this, I’ve realized that there is quite a bit of commonality between the strengths of Qt and some of the new directions in Ubuntu.”
The reasons for this new insight shouldn’t come as a surprise. Ubuntu is moving into mobile, and Qt has a long history there. Qt is very cross-platform, also very important to Ubuntu. Last, but not least, Qt has a pretty decent touch input framework, which, in this day and age, is a must.
“I think Qt has a lot to offer people who want to develop applications for (and on) Ubuntu, particularly now. It already powers popular cross-platform applications like VLC, not to mention the entire Kubuntu distribution,” he concludes, “It has strong commercial backing as well as a large developer community. No single solution will meet all developers’ needs, of course, and Ubuntu supports multiple toolkits and frameworks for this reason, but Qt seems like a great tool to have in our toolbox for the road ahead.”
Maybe this will mean Canonical will devote some time and money to the KDE project as well, which should eventually pay out for Kubuntu as well. Seems like good news all-around to me.
“Qt has a lot to offer Ubuntu…”
Funny, you wouldn’t know it from the sad state of Kubuntu presently.
Clearly a person who hasn’t tried Kubuntu on 10.04 or 10.10. Its fine except for Kwin within KDE 4.5 with the ATI open source drivers just now, but that is a problem for any KDE 4.5 installation not just Kubuntu, and the only effect is to disable compositing. One can use compiz for KDE as a work-around.
In every other facet, Kubuntu 10.04 or 10.10 gives you a great desktop with a fine set of well-integrated KDE SC applications, and it is completely free of Mono as a bonus.
Take your mono trolling elsewhere.
We get it, you don’t like mono, so stop bringing it up in every other article already.
Yer. Just where are all those .Net applications that could be turned into cross-platform ones and run on a Linux desktop under Mono…….?
Right there with all other win32 applications that got turned into ‘multiplatform’ by wine.
So it’s fine, unless you have an ubiquitous video card in which case you’ll have to disable default features in order to get things working?
Drivers fault or not, it’s all part of a package and the package suffers for it. Having to search for workarounds after installation does not engender good first-impressions.
Thankfully my test machine uses an Intel chipset which seems well-supported (if a little sluggish). Overall, my personal first impressions are actually quite positive. If it can work with my Samsung MediaLive…
Edited 2010-10-20 23:58 UTC
This affects only a few ATI and Intel cards, BTW.
You don’t have to disble default features if you don’t want to: alternative options are to use compiz for KDE instead of Kwin, or in the case of R600/R700 ATI cards you could use the proprietary fglrx driver instead of the open source ATI driver.
Yes … but not the Kubuntu package, it is KDE 4.5 SC that is affected. This is just as true for Fedora, Arch, OpenSuse, whatever … it is not a Kubuntu issue.
Yes, it is only a few cards affected, it is affected for KDE 4.5 SC only (on any distribution), and it affects only the desktop compositing, for which an alternative (compiz for KDE) may be selected.
Not the best I grant you, but given that a few work arounds exist it is not an absolute disaster either. Remember also it is not a Kubuntu issue, not an issue for most graphics cards, and not a Qt issue.
You don’t get it. Kubuntu suffers because people with those cars will be forced to do workarounds. Kubuntu should repackage KDE so that the workarounds are already present directly after installation if you’re video card doesn’t support certain features.
The same goes for any distribution or anyone who create packages.
I don’t get the why some people blame up/downstream for bugs? If your stuff uses broken stuff you can’t just ship it to people and tell them: not my fault. Work around the bugs in the software you depend on, depend on other software, anything. Just don’t be lazy.
if (upstream has bug) { work around bug }
else { do it the normal way }
Remove if when possible later on when bug is gone and you are cleaning up the code.
In the end, users will blame Linux, even though it’s a kernel. So stop blaming each other and come up with solutions and try to ship working software.
(Oh, not really accusing you, lemur, for shipping bad software, btw
)
Edited 2010-10-21 01:06 UTC
I have issues with compositing and an nvidia card.
Same comments apply: either install and then select compiz for KDE instead of Kwin as the default Window manager (via the default applications in system settings), or use the proprietary nvidia driver.
I wish that the Kwin developer hadn’t saddled KDE 4.5 and every single KDE distribution with this issue, but it has been done now and if you are affected then you will need to adopt one or other of the workarounds if you want to use KDE 4.5.
I repeat for those who are apparently having a bit of trouble following this: this is not a Kubuntu issue, it is a KDE issue, specifically with the Kwin window manager in KDE 4.5. Every distribution that ships KDE 4.5 will have the exact same issues.
Edited 2010-10-21 13:25 UTC
The problem with NVidia _is_ with the propritary NVidia driver. The new open source drivers works fine. First the binary driver had a long range of performance problems slowing KDE down, and now with most of performance problems solved (as long as you use OpenGL composition at least), all the latest versions have had large memory leaks in the GL driver
Edited 2010-10-21 17:58 UTC
That is unless you want to unlock nVidia’s 3D and support compositing.
With Gnome you can use the proprietary drivers and use Compiz
Clearly, you’re wrong! Actually, I’ve had Kubuntu running on my laptop since Kubuntu 9.10. KDE 4.x, itself is absolutely fine. What’s missing is the myriad of customizations Canonical bakes into its Gnome based Ubuntu. Very few, if any customizations have made it into Kubuntu which is why I stand by my statements. Kubuntu really doesn’t offer much apart from a stock KDE implementation or anything unique from Canonical to separate it from the myriad of other better KDE offerings from Sabayon, Linux Mint, or Mepis. Canonical and the Ubuntu devs treat Kubuntu like an afterthought. It’s little more than an Ubuntu base install with the (vanilla) KDE packages and a few different default applications. And they call it a distribution. Really?
Edited 2010-10-21 00:13 UTC
If Kubuntu has nothing to distinguish it from KDE offerings from Sabayon, Linux Mint, or Mepis (or OpenSuse, PCLinuxOS, Mandriva, Slackware or Knoppix for that matter where KDE is also the default), then how are any of the other offerings “better”?
Kubuntu 10.04 is an LTS distribution. It uses debian .deb packages and hence apt/aptitude package manager backends. It can add any of the Launchpad PPA projects to expand the number of applications that can be installed. It can install any Ubuntu package (most of them don’t assume GNOME but only gtk+ support BTW). This gives Kubuntu the largest selection of installable packages (that can be installed from repositories) of any KDE distribution.
This alone IMHO makes it worthwhile.
Frankly I’m struggling to see any Canonical customisations that could be applied to Kubuntu that would be worth it.
PS: I have thought of a few worthwhile Canonical customisations. These are: upstart (quick boot process); jockey (install proprietary graphics card drivers); Ubiquity (distro installer); GRUB 2 and automatic detection and configuration of printer drivers when the printer is first plugged in.
Kubuntu has all of those.
Edited 2010-10-21 00:42 UTC
Have you used OpenSUSE? Have you tried SimplyMEPIS? Have you given Sabayon’s KDE offering a good workout? Have you even looked at Linux Mint’s community KDE edition? Based on your comments, I’m fairly confident the answer is “no.”
The answer is “Yes” apart from Sabayon. I tried Sabayon some time ago, new applications took ages to download, compile and install and it was possible to get yourself in a twist.
I also tried PCLinuxOS BTW, Arch (KDE) and Fedora (KDE variant).
The latest versions of MEPIS, OpenSuSe and Linux Mint community did not properly detect my video hardware on boot of the LiveCD. They all started in a fallback vesa graphics mode with the incorrect resolution for my LCD screen.
MEPIS, PCLinuxOS, Arch and OpenSuSe have quite small application repositories compared to Kubuntu.
Only Mint KDE included the Canonical improvements: upstart (quick boot process); jockey (install proprietary graphics card drivers); Ubiquity (distro installer); and automatic detection and configuration of printer drivers when the printer is first plugged in.
All things considered, partly due to the contributions of Canonical, Kubuntu is the best KDE distribution available right now.
Edited 2010-10-21 01:30 UTC
What the grandparent was saying was that Kubuntu’s KDE has little to distinguish it from stock KDE, whereas the other distributions mentioned have added value in the form of defaults, integration, tools, etc.. By comparison Kubuntu KDE is weak.
But how exactly is it supposed to be weak?
By virtue of using the same OS mix underlying the desktop as Ubuntu, it has the best underlying OS features, such as apt and upstart.
It has the best repositories and the best “additional application” installer.
It has the best community support via Launchpad PPAs.
It has an extensive community-users-cooperative-help forum.
All of these features are provided through Canonical’s involvement.
If we are talking about just the configuration settings and the theme out of the box … all of those are user settings anyway. Just configure it how you would like, it is as easy as pie.
What exactly is wrong with the default settings as provided by the KDE project compared to the default settings as adjusted by other distributions? How does changing the default wallpaper and the default Plasma theme make other distributions supposedly better than Kubuntu?
Is that it? Is that the complaint? That Kubuntu doesn’t change the wallpaper and the default Plasma theme away from the KDE defaults?
Let me quote Colonel Quaritch: “You have got to be kidding me!”
Edited 2010-10-21 13:23 UTC
Try using some nicely integrated KDE distros. There’s a lot more to a complete system then “We compiled everything upstream released” and not understanding this is *the* single biggest thing holding back desktop Linux.
Go ahead, tell me it’s fine and there are no problems. I’m glad you’ve got everything you need.
So you can’t actually come up with a real problem that Kubuntu in particular has, I take it?
You can’t actually point out a solid example where Kubuntu isn’t nicely integrated compared with another KDE desktop distribution, so you thought you would just try and lob the ball back in my court?
I’m lobbing it back again.
I don’t really see anything wrong with that. Then again I’m an Arch user and one of the things I love about it is the fact they keep things as vanilla as possible. I view distro additions as the linux equivalent of all the bloatware that comes on new Windows PCs. A vanilla install is the way to go in my opinion.
Semantics are fun. KDE generally implies QT usage, but the reverse is not true at all. Plenty of open source and proprietary applications that use the QT toolkit have no relation at all to the KDE project.
Well said, and very true! The original article talks about Ubuntu+Qt, not Ubuntu+KDE.
To make it work you can’t just have a desktop shell running Qt applications. That just isn’t going to work.
Works perfectly fine for cross platform apps like Virtualbox does it not?
It does until you start hooking into desktop infrastructure – filesystems, media libraries, application components…..
That’s what creating a development and coherent deployment environment demands if that’s what you’re presenting to people.
> Funny, you wouldn’t know it from the sad state of
> Kubuntu presently.
I use the present Kubuntu and I know what I’m talking about. You could try it, too, and tell us where is the “sad state” instead of talking before thinking.
Am I the only one who thought Thom was going to make some snarky reference to the Zimmerman Note of WWI?
Edited 2010-10-20 22:57 UTC
I certainly did
I thought of Bob Dylan… Go figure…
Makes perfect sense. It is hardly a secret that Qt is technically superior to Gtk+. The only reason Linux hasn’t more or less standardized on Qt is because of historical reasons. There used to be a lot of confusion and uncertainty about the licensing of Qt, which is why so many apps settled on Gtk instead.
Besides, the differences in look and feel are not that gigantic anymore. The community and also Ubuntu has done a great job integrating both UI toolkits. I bet many people (even Linux people) don’t even know VLC, for instance, uses Qt. And as already has been said, KDE is not equal to Qt. KDE merely uses Qt, but Qt is broader.
A greate job indeed, but the statment is not correct. All intergration work has been done by the KDE and Qt community, the Nokia Qt developers and developers from Novell/SuSE. In that area Ubuntu has done nothing, expect packaging the work done by others for their distribution.
Ok, wasn’t aware of that. Thanks for the information. But that doesn’t change the outcome.
Then they need to invest some resources into making QT communicate properly with the GNOME accessibility infrastructure. Otherwise, to use QT will directly contradict one of Ubuntu’s stated goals, i.e. to provide an accessible desktop to all people. Not that I’d be surprised if they did go against this stated goal of theirs, they’ve certainly made decisions that sneared at it before such as using Webkit over Gecko in their core apps like Software Center.
I don’t complety agree, OSX has cocoa, Windows has MFC and .NET, Linux has ???, what it needs is a dedicated Linux/X.org toolkit, Qt tries to be “everywhere” and for that it gives mediocre results, so drop the multiplatform stuff, is not needed, work in something that works good in Linux and dedicated to Linux.
What a strange thing to say. Being multi-platform equals “mediocre results”? Waste of time and resources maybe? I don’t agree.
I’m no developer but if I could focus on just one toolkit to write applications with, I’d consider one that takes multi-platform seriously. Linux/GNU (on desktop especially) would be a different place if apps like Firefox/Chrome/Thunderbird for example only ran on one platform.
It is mediocre on Linux, it render the fonts in a fugly way, the cinerama support is less than mediocre and the geometry bugs QGraphicWidget has is beyond tolerance.
And the worse, it is controlled by Nokia, hence semi-propietary, it is Nokia who desides what bugs are prioriry, what’s gonna be the license of the next version and of course it desides when an API gets deprecated (see QGraphicsWidgets and KDE4), so an independent toolkit is a must, we are talking about a toolkit for Linux, being multiplatform means nothing, it means it will be mediocre in one platform or another.
Edited 2010-10-21 01:08 UTC
Qt is licensed as LGPL v3 (not just GPL, mind you, but LGPL), which makes it decidedly not proprietary.
BTW, it was Nokia who made it LGPL. Qt wasn’t LGPL before Nokia purchased it.
Being LGPL means that you can statically link it, and then distribute it as a binary if you like. MythTV comes to mind here.
Qt is being embraced by Intel within the Meego framework.
what part of “what’s gonna be the license of the next version” you didn’t get?
What part of “BTW, it was Nokia who made it LGPL. Qt wasn’t LGPL before Nokia purchased it.” don’t you understand?
The next version AFAIK will also be LGPL v3, but what does it matter since the current version (Qt 4.7) is LGPL v3?
If Nokia withdraw subsequent version of Qt as no longer GPLv3, (which would be suicide BTW for Nokia’s involvement in Qt), then the community would simply fork Qt 4.7 and move on.
While Nokia continue to keep Qt as GPL, then the community will continue to support them.
Right now, Nokia enjoys considerable support, help and contribution from the community.
Edited 2010-10-21 01:42 UTC
No, you don’t now for shit what’s the next version is going to be, so don’t speculate.
Considering Nokia loosened the licensing terms when they purchased Trolltech, plus their push for Meego as an open platform for phones/tablets, which QT is their main contribution, I think it is a safe assumption that QT will remain LGPL.
You are attempting to spread fear, without a slightest bit of evidence, that Nokia may close the platform, despite already opened it up further than it was before.
Stop spreading FUD, troll.
Truth hurts, I now. be cool
Geesh, what the hell are you babbling about? Qt was before MORE restricted than it is now, Nokia opened it up. And hell, even if Nokia for whatever reason decided to change the license the currently released version would still remain LGPLv3. They can NOT retroactively change the license on already released versions.
Thus, even if a miracle happened and they decided to shoot them in the foot by closing Qt up people could still continue to use the current one and just fork it and continue on improving on it.
Now, will you please shut the f*ck up and stop spreading completely unfounded speculations and try to scare people away from Qt?
I gave my opinion, you don’t like it. is you problem.
No what you gave was no opinion but rather lies.
What lies? I said that is Nokia who controls what’s the license of the next version is gonna be , what bugs are priority and what API gets deprecated, so where is the lie? Oh, I see, you are to biazed to see.
I also said it opossed to ogg as HTML5 standar, that is using patents to sue the competence and that is being acussed of human righs violations and opression:
http://www.eff.org/deeplinks/2010/10/saharkhiz-v-nokia
So tell me, where is the lie?
Edited 2010-10-21 13:34 UTC
“And the worse, it is controlled by Nokia, hence semi-propietary,”
First lie. It is GPL and LGPL you can fork it _anytime_.
“it is Nokia who desides what bugs are prioriry,”
That is the same for any other main contributor of a FOSS project, so again FUD.
Torvalds decides what he pulls into the kernel as he is the maintainer. That does not make the kernel “semi-propietary” though. FOSS is not about that anybody could commit anything they like, but rather that you can commit anything you like if you fork it.
You want the BFS scheduler? Don’t expect an offical kernel release to include it.
You want QtJava? Don’t expect an official Qt release to include it.
In both cases none is stopping you of implementing it yourself and in both cases it happened, yet not as part of the offical project.
“it is Nokia who desides what’s gonna be the license of the next version”
FUD, the can decide for their code — which is in fact most atm — but not for the whole project since the copyright of committers does not have to be assigned.
Thus they can release a version of Qt with a different license but would have to split out any outside contributions if the contributors do not agree to the new license.
Basically they would have to fork their own work to relicense it.
And that is something any contributor of a FOSS project — without copyright assignement — can do.
“and of course it desides when an API gets deprecated (see QGraphicsWidgets and KDE4), so an independent toolkit is a must”
That again is true for any FOSS project. The maintainers decide what gets deprecated. Keep in mind that a lot of FOSS projects don’t even make a promise on the API as Qt does.
“we are talking about a toolkit for Linux, being multiplatform means nothing, it means it will be mediocre in one platform or another.”
Same is true for GTK.
Multiplatform is quite important for developers, write once (maybe slightly adapt it) and use it everywhere. Maya e.g. uses Qt nowadays.
This ensures that users of your apps have a consistent experience, no matter if they use it with Linux, Windows …
Multi platforms also means that it is easier for small projects to gain a lot of programs for free, be it Haiku or eComStation. You port the toolkit and can use a lot of programs (you have to recompile them in fact) right away on your platform.
“And the worse, it is controlled by Nokia, hence semi-propietary”
I don’t see any concesus around Qt, despite the license it is Nokia who desides the fate and controls the repository, so I don’t see any lie there.
And there is a concensus in the kernel, Linus by him self doesn’t deside, there is a comitte and there isn’t one in Nokia’s, they have the last and only word.
The second point is not FUD, since they control what contributions to include they are prepared to dispose them at every moment, it may look like FUD to you but certaintly is not a lie.
And multiplatform has proven that is worthless, standars are the one that matters, there are countless of examples that work better using the native toolkit and are multiplatform, Chrome, MS Office, PhotoShop, etc. All those are multiplatform and use native toolkits hense they can squise every resourse of the native OS, that’s what I mean, Linux needs a toolkit that vendors and developers can squise at the maximun and not fall in the common denominator.
And you didn’t answer the HML5 standar and opression issues, so, you are just cherry picking parts of my posts.
Edited 2010-10-21 15:56 UTC
That is a lie. The maintainer decides. And yes Linus Torvalds decides a lot he sometimes disregards patches as untested bs.
The thing is anything you state here applies as well to any other FOSS project whose maintainer is also the main contributor.
MariaDB, Go-OOo and LibreOffice prove you wrong.
As long as the whole FOSS community can live with a maintainer there is no reason to fork, if large problems arise you’ll see forks arise.
Btw. using Qt does not mean that you can’t “squise every resourse of the native OS” and there are enough successful projects like Mathematica, Maya, VLC, Skype, Virtualbox … using Qt (even Adobe Photoshop Elements) or other multi platform toolkits, so your argument is kinda mood, again.
On the cerry-picking part: You miss the point. This here is about Qt and it being FOSS not about HTML5 or human rights violations. So rather stick to the topic!
No, you are wrong, in the Linux kernel there is a concensus, RedHat, IBM, SUSE, etc, it may be the case when a contributor doesn’t ask for concensus in a bug fixing issue.
But in Qt is Nokia only, there is no concensus at all.
And no, Qt can’t squise all the Linux resources, it doesn’t use the X render for fonts it use its own and does it in a fugly way, and why does it that way? because it has to feet in with Windows, OSX, etc. They can’t server 2 master or more, Linux needs a dedicated toolkit. And is just a simple example there are more.
All those projects are mix of native hacks and Qt as the presentation layer, VLC btw look ugly in all platforms, they should have sticked to GTK on Linux now is awfull on Windows, OSX and Linux.
And yes it matter when a company that devious behavior has it its hand the fate of a toolkit of an open platform.
And you can read some of teh workarounds Qt needs to be multiplatform:
http://byuu.org/articles/qt
See? it gets mediocre when it tries to serve 3 master or more.
Edited 2010-10-21 16:55 UTC
Go read up the GPL and LGPL license, I really don’t see what the problem is here. As if the maintainers of GTK implemented every patch you send them…
You also did not comment on their new governing system with open ml, bug tracker, discussing of features etc. even did not mention that you don’t need to assign copyright.
“And yes it matter when a company that devious behavior has it its hand the fate of a toolkit of an open platform.”
In what way?
What you propose is not realiseable in FOSS. There aren’t enough resources and knowledge to do everything multiple times with different toolkits. Yes for sure native will always be the best solution, but is it pragamatic? I suppose not. That is the whole reason behind programming languages, abstractions etc. to make it easier to develop something. Yes devs shouldn’t be in the center, but of what use is a never finished program/port for the user?
On that link you posted, yeah bugs suck. Still there were reasons for QList QVector et al. and do you know them?
Also mentioning C++0x … that is not even standardised. There are still compilers not fully complying to C++98 let alone C++03.
That’s my point, GTK has a concensus who desides what goes in, Qt doesn’t, it is Nokia and only Nokia who desides.
In what way? [(i]
Haven’t you see the the lates Oracle/Open Office drama, a trust worthy comany its a must and Im sorry, Nokia is not trust worthy.
[i]Edited 2010-10-21 19:04 UTC
And even that objection is being addressed:
http://labs.qt.nokia.com/2010/06/03/qt-and-open-governance/
Doing evil does not serve Nokia’s interests at this point. But for the sake of argument, let’s play the scenario where Nokia decided to clamp down on free Qt. The only way to do it is to relicense it under a more restricted license than LGPL (like, say, dual GPL + commercial).
Likely outcome: someone (Google? Intel? Red Hat? ) recruits all the Qt developers; they would be happy to ditch a company the killed Qt. They would pick up where they left (i.e. branch from the last LGPL’d version from gitorious). Nobody would see any difference, apart from Nokia that would be pretty royally screwed.
While corporations shouldn’t be trusted, you can pretty easily determine which companies profit from evil (Apple, Microsoft) and which don’t (Nokia, Intel, Red Hat, Novell…)
Edited 2010-10-21 19:36 UTC
And then, there’s still the agreement KDE has with Nokia that basically puts the last version of Qt under BSD if Nokia stops releasing Qt as free software.
That’s kind of the sad little plan. 😉
I especially liked the license thing. For years these people had a massive go at Qt for being GPL licensed. Then it gets LGPL licensed and people…….go quiet. But hey, the license could be changed! I mean there’s no central copyright assignment so Nokia would have to go around and ask for everyone’s permission, but it really doesn’t matter how small that probability is.
It’s a laugh a minute on these articles.
Edited 2010-10-21 17:31 UTC
I should be obvious by now that the guy is just trolling.
In a previous article on plasmas move to QgraphicsScene he had his objections very well explained in the comments. An yet in this article he comes with bombastic statements that QGraphicsView is being deprecated. I seriously doubt that even if QGraphicsView were to be deprecated it would make zero difference to him really.
Likewise with license changes.
Im pointing the problems of using Qt as a linux toolkit, the othe post is related so you see me here in the same position. So no, is not trolling, check the facts.
Sorry. It was just my opinion on what you said. Since It is an opinion, It can’t be wrong…
There is no speculation involved at all on my part in pointing out that Nokia’s only decision to date regarding the license of Qt was to choose LGPLv3 for it.
That is a plain, straightforward, well documented fact.
GPLv3 or version x. not for version x+ that’s speculation.
It is indeed speculation. Totally unfounded speculation. Wild speculation. Speculation on your part alone, that no-one else has bought in to at all.
Edited 2010-10-21 02:49 UTC
Im glad you see my point now.
Nokia will surely use LGPL as a license for 4.7. Their acts speak to them — so far.
But even if they preferred to make it proprietary and never released the code, the open source community would still develop an LGPL Qt 4.7. Nokia couldprevent that, even if they wanted.
Their acts speak to them
That’s so true, wasn’t Nokia the one who oposed to ogg video as a HTML5 standar? and the one who is know using patents to sue the competence? What does that speak to you? oh and ain’t Nokia being acussed of human righs violations an opression?
http://www.eff.org/deeplinks/2010/10/saharkhiz-v-nokia
Edited 2010-10-21 03:34 UTC
As it is, not only would the comunity have that option the last Qt release would become released under a BSD license making it possible for anyone to make their own proprietary version if they so wishes.
Hiev, stop talking out of your back orifice. Nokia dropped their requirement for copyright assignment in May 2009.
Our goal with the new site is to make this process as simple and welcoming as possible, and that’s why we will no longer ask for copyright assignment.
http://labs.qt.nokia.com/2009/05/11/qt-public-repository-launched/
So even if Nokia would want to relicense, they would have to ask permission from every outside contributor or rewrite every outside contribution themselves. This makes the probability of a license change pretty low.
Also, don’t forget the great strides Nokia is making with their open governance model. It definitely is something they are really focused on, witness the various presentations at the Qt Dev Days.
every, i mean every open source project does have somebody in charge that controls it and make decisions that others could not like, that’s life.
yes, it’s possible some day they could decide to close it up or cease the development, trascuring for a moment that would be a suicide and is really unlikely, let’s assume for a moment that it happens. Now, they can’t *legally* change retroactively the license of already released versions, more than that, the KDE free Qt foundation makes sure with a legally binding agreement that all they did put in qt until that moment is released under an acceptable license.
So what would happen would be that the development would be made move forward by individuals (and there are maaany people around that know the internals enough), and yes it would suck, yes, it would slow down, but would just become like many other open source projects at the moment
now, all of this won’t happen, because Qt is making great progress towards open governance. And i mean not only accepting patches like now, but even opening up some of the *decision making* processes to both individuals and different companies. This among other things ensures that as many people as possible (and with different interests) have a say in it, ensuring that
a) doesn’t go in a direction that favors only one use (or company)
b) relicensing become a lot harder
Obviously you don’t get it.
Nokia accepts outside contributions and does not even ask to assign the copyright, thus if they changed the license later on all outside contributions would need to be removed.
And in fact it is the main contributor who sets the priorities, but that is the same for ANY FOSS project, be it Qt or Nokia. Further looking at gitourious you can see that also merge requests for features are accpeted.
I am a developer, and yeah, you end up with mediocre results.
Problem #1 is that windows and unix based operating systems take a fundamentally different view of processes and how to do parallel programming. This is why apps like apache/mysql etc while ported to windows, don’t work anywhere near as well.
Problem #2 is that operating systems have different capabilities. You end up having to take one of two approaches — either go for the lowest common denominator, which means you won’t be able to take advantage of fancy things on any given os, or build and maintain your own feature set, which is way more work and gives inconsistent results across operating systems.
Problem #3 is that operating systems look completely different. Either your UI looks the same (and out of place) on all operating systems, or you go for the native widget approach. The problem with that is you basically need to maintain different code for each OS, because a checkbox on windows has a different size then on OSX, which is different then gnome, etc. Also, design wise windows and kde are similar, and osx and gnome are similar, but when you mix over those boundaries things just seem wrong. An osx app to a windows user will seem simplistic, and a kde app to a gnome user will just look like a mess.
The best approach a cross platform toolkit can do go for “portability”, i.e. minimize the amount of work you have to do to support multiple platforms, not try to maintain compatibility.
You gave firefox as an example, it is a great one. It was developed primarily for windows for years, and until fairly recently, actually ran faster in linux under wine then natively. That is because of how hard it is to do things right behind the scenes on all platforms. What they did do was the whole cross platform UI thing. But chrome has managed to grab 8% of the browser market (mostly from firefox) over the last two years because of how sluggish the firefox UI is in comparison.
Now, all that is a general rant on cross platform toolkits. Qt is actually one of the better ones, and probably would be what I would use if I had to write a cross platform client app. But in a general way, cross platform is a synonym for “worst of all worlds”.
This was true for one release, but only because the Windows build only had been optimized via a process called profile guided optimization.
http://en.wikipedia.org/wiki/Profile-guided_optimization
This optimization wasn’t done by Mozilla for the Linux build they distributed. At least a few distributions, SuSe I think was one, did however do it for the build they distributed. SuSe also made patches for Firefox to give it better integration with KDE, even to the extent of using native KDE dialog boxes.
I think Arch may have picked up on SuSe’s work:
http://aur.archlinux.org/packages.php?ID=22296
It is not the primary design of an application that makes it fast or slow under one OS or another, it is the little details of how it is tuned and built that matter.
MFC is just a (horrible) C++ wrapper around the win32 API. Qt is also a wrapper around the win32 API on Windows.
Not true. Qt draws all its widgets itself (but it does use the platform theming API on Windows at least).
True. Qt does theme emulation, otherwise it would have a very, very hard time making cross-platform applications have the same general layout on each platform – which is what is needed with cross-platform apps.
Doing it by hooking into each and every desktop and letting them do the drawing is what systems like SWT do, and it creates a lot of baffling and very hard to solve bugs from time-to-time.
Here is a description of the Qt framework:
http://en.wikipedia.org/wiki/Qt_%28framework%29
Here is an incomplete list of packages that use Qt:
http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
By no means are all of these KDE packages, and many of them are worthwhile cross-platform packages.
Notable non-KDE packages which use Qt include: VirtualBox, DAZ Studio, Scribus, VLC, SMPlayer, LMMS, QtCreator, QtQuick, Skype, Gambas, Google Earth, Lyx, TeXworks, PDFedit, QCad, Mathematica, MythTV, Avidemux, Avogadro, Arora (browser), MuseScore, NoteEdit, Rosegarden and Transmission (BitTorrent client).
Why should Qt limit itself to Linux?
Cocoa is multi-platform (Cocoa touch).
.Net is multi-platform (WP7, Mono).
MFC is legacy and is not an universal framework.
Your point ?
Edited 2010-10-21 05:16 UTC
Cocoa works on Apple platforms, .NET on MS platforms, news at eleven.
Qt applications work for desktop environments (Windows, Linux, and Mac OS) and mobile devices (Symbian, Maemo, and MeeGo).
Develop your app for a much wider market with no extra effort.
And that’s why it is mediocre on Linux.
Linux needs a dedicated toolkit not one that want’s to be “everywhere”.
That really has no logic. Qt apps are compiled for the target operating system.
Qt Quick is by far the most advanced and easy way to create rich and well designed apps on Linux. That alone is a big reason to use it on Ubuntu development.
> “easy way”
Talking about this, compare the simplest program, “hello worldâ€:
http://en.wikipedia.org/wiki/Gtk#GTK.2B_hello_world
http://en.wikipedia.org/wiki/Qt_%28framework%29#Qt_hello_wo…
The difference is big. Fundamental.
lol, you should see a Qt Quick hello world then:
import Qt 4.7
Text {
text: “Hello World”
}
you do realize that you’re looking abysmally stupid by comparing an ad hoc markup-meets-logic language with a C implementation, right?
no, I mean: you do, right?
Hmmmm. You do realise that those two sections of code are functionally equivalent and do the same things right?
I agree, but it does seem to be limited to fixed size applications (i.e. for mobile phones, tablets, TV interfaces etc). It would be cool if you could make normal desktop apps with it.
They might as well, just create a GTK-compatibility layer so all existing GTK-apps work with QT.
There is no point to do this. Qt have a compatibility layer to run as gtkish as it can. Usign GLIB and GTK design guide lines. Ubuntu will(should) nerver switch design guide lines, invert ok and cancel and that kidn of stuff. Keeping Qt in GTK mode is the only hope to maintain some level of consistency.
Nokia should set up some sort of “blessed” bindings program. The only firm choices to use Qt now are C++ and Python. No other path is really trustworthy. This needs to be expanded at least to the JVM(Java), CLR(C#), and javascript(a node.js for the desktop). Jambi was killed(OK, ‘given to the “open source community”‘) way too soon…
It is possible to script everything in Qt with QtScript, that uses the WebCore javascript runtime.
Actually you can expose any QObject you want, choosing what methods/properties will be available from within js
I’m one of those fellows that refuse to install a Qt app on my GNOME desktop… for the same reason I don’t like install a Java app. It behaves and looks differently than the rest of my apps.
I’ve tried KDE – but it’s ugly in my opinion, and not as polished as GNOME.
That’s my perspective as a user. However, as a developer I’d be absolutely thrilled if there was a GNOME-like DE developed in Qt – that would rock.
In some respects I am similar … I don’t like GNOME applications on my KDE desktop. Gtk+ applications are tolerable, because KDE can integrate them well enough, but GNOME apps behave badly and they don’t look good.
Not to worry though, most of the GNOME apps are over-simplistic and not flexible enough to bother with much. Using KDE I get to run all of the integrated-with-each-other apps in the KDE SC, and I can run Qt-based non-KDE apps and they are right at home and well integrated also, and even the gtk+ apps don’t jar too badly except perhaps when it comes to a clumsy and limited GNOMEish file picker dialog box or the like.
Beauty is definitely in the eye of the boholder, it would seem.
VLC has to have the worst UI of any video app ever made. I would hardly hold it up as a shining example…
_maybe_ skype, although that is an example of an app that looks great on anything except for ubuntu.
I agree with most other people here for the same reasons — qt apps dont look, feel, or act like gnome apps, and it would be pretty dumb to go down that road. Not to mention the overhead of loading two major gui toolkits into memory for one or two distro specific apps.
Qt will benefit from this collaboration too. Technically Qt is a great toolkit, robust, portable, fast, easy to deploy and so on. But there is a lot of work to be done on its esthetics and usability. Perhaps I’m spoiled by Gtk themes but it’s hard to find a pretty yet readable Qt style (“cleanlooks” is not bad but still much worse than its Gtk counterpart).
Also, the UI design tends to be a bit clunky in an “MS Office 2003” way – all that moveable panels, splitters, toolbars waiting to be moved out of sight. Give any Qt application to my mother and she’ll “break” it in 15 minutes.
(It’s kind of funny that although as a user I prefer Gtk, I use Qt in my applications.)
Have you tried QtCurve?
I find it hilarious that GTK+ fans come along and talk about how nice their themes are compared to Qt themes. It seems that all they’ve seen is Keramic and Plastik. There are other themes and unlike GTK+ they are configurable via the GUI and often in surprising and useful ways. QtCurve has a ridiculously comprehensive theme configurator. You can make QtCurve-based themes that look surprisingly dissimilar from one another. It also supports GTK+ and will share settings so that your apps look the same (more or less) despite using different toolkits. It can even do things like button order-switching and icon substitution if that’s your thing.
I’m hardly a Gtk fan. If you actually read my comment you would see that I actually prefer Qt to Gtk in most respects. It doesn’t change the fact that Qt is simply ugly and looks messy (or encourages design of messy GUI).
I’ve tried all styles shipped by default with Qt and even went ahead to try some free third party ones. Looks like no one has a good taste there – all styles feel like a broken copies of some well known LaF’s (Motif, Clearlooks, Gtk, Blue Curve, Windows) or look like made by children (Oxygen, Plastic, Keramic)
QtCurve (also windowsxp style on XP) is indeed one of the best among them, it works and is readable. But it is simply an old theme and its aesthetics match the state of art of 2003.
There are nice Qt themes but these all seem to be reserved for proprietary products of some third party products. Mentor, Cadence have both developed nice and clean themes. So it is possible, only we can’t rely on good taste of Nokia employees (or KDE guys). This is where Ubuntu’s contribution could help a lot.
If you like the way Gtk looks, just use QGtkStyle. It’s the default when running in Gnome on Ubuntu.
Two comments:
– I tried Qt4.7 and I actually like the way cleanlooks looks now. Not sure what’s the difference (my old Qt installation is gone now) but I’m happy with the readable, modern yet modest look of my app. It would be nice to have more styles of this quality in Qt, perhaps reproducing some of the best LaF’s out there.
– Gtk style is fine for simple applications using basic widgets but for many others it breaks pretty badly. For example, QGroupBoxes or QDockWidgets lose most of their visual indicators, which makes them rather unreadable. That’s perhaps inline with what Gtk does but it simply looks wrong (perhaps due to different text alignment rules etc.). Gtk style feels a bit like an automatic text translator – sort of works but its output isn’t really what you’d like to show to your customers/users.
Beauty is in the eye of the beholder.
Personally, I can’t stand GTK+ apps, regardless of what theme is used. Everything is “flat” and boring and blah, and always remind me of Netscape 4.x. There’s no depth to anything, and colours are always muted, reminding me of pastels or hostpital shades of colours.
QT, and especially KDE, apps always look more professional, more complete, and more useful to me.
But, that’s the beauty of things … you can use the GTK+ apps you like, and I can use the QT/KDE apps I like, and we can both be happy.
Thankfully, the QT devs seem willing to bend over backwards to make GTK+ apps integrate into a QT-based desktop, even going so far as enabling the use of the glib even loop. It’s too bad the GTK+/GNOME devs seem hell-bent on preventing the opposite, making QT apps look alien in GTK+-based desktops.
Edited 2010-10-24 18:48 UTC
I’ve heard a lot — including in this article — about Qt’s technical superiority to GTK, but searching online only seems to bring up entirely one-sided fanboy comparisons with little technical detail.
So, could anybody tell me briefly, what is it that makes Qt so much better? What can you do with Qt that you can’t do with the combination of GObject, GIO, GTK, Cairo, Clutter, GStreamer, and so on?
This isn’t a troll, I’m genuinely curious: I know quite a lot about programming the “G” world and next to nothing about the “Q” (or “K”) worlds, and I’d like to expand my knowledge.
I’m not a developer, but surely this would be a start:
http://qt.nokia.com/products/developer-tools/
http://en.wikipedia.org/wiki/Qt_Creator
http://en.wikipedia.org/wiki/QML
http://en.wikipedia.org/wiki/Qt_Quick
http://en.wikipedia.org/wiki/Qt_Creator#Version_Control_Systems
http://en.wikipedia.org/wiki/Qt_Creator#Qt_Simulator
http://en.wikipedia.org/wiki/Qt_Creator#Targets
Find out more here:
http://qt.gitorious.org/qt-creator/pages/FrequentlyAskedQuestions
Thanks, but perhaps I should have been clearer; my query wasn’t so much “how can I learn about Qt”, but rather *why* should I learn about Qt? What would it get me? Why is it better than the technologies that the Gnome world uses?
You can find a lot of things saying “Qt is superior” without any real details about what makes it superior.
Again, this isn’t meant to be a troll or an invitation to a flamewar. Like I said, I know quite a bit about GTK development — I do it for a living — and I’m wondering what it is I’m “missing out on”.
The benefits I found (I started using GTK then switched to Qt), in order of significance.
* Signals/slots. They may be slightly hacky, but it is hidden well and they really are the easiest way to code UIs. Much better than callbacks (wxWidgets, GTK) or message passing (MFC).
* Documentation. The Qt documentation is one of the best of any project I’ve used. It’s very comprehensive, and tells you exactly what you need to know. It’s like the opposite of Android documentation.
It’s comparable, but slightly better than the MySQL, or MSDN docs.
* It’s real C++. It isn’t a hacked up a “C++ in C’s clothing” using endless macros and casts like GTK is.
* More comprehensive. It includes way more useful stuff than just low-level UI things. Particularly QtXML, QtWebKit, QGraphicsView, and the network stuff.
* Qt Creator (ok, this didn’t exist when I started using Qt, but still). It rocks. A sample of the many awesome features: 1. It supports smart tabs! 2. Code-completion actually works *cough* KDevelop, Anjuta *cough*. 3. Ctrl-click anything to go to its definition. Very useful.
* Performance on Windows. It doesn’t suck. And it looks native, unlike GTK.
There’s simply no reason to use GTK over Qt today. The only real reason was the licence, but that is resolved.
I would add a few:
Cleanly designed
Visual Studio tie-in
Bindings support
Better team leaders and funding
They still have some native control and font issues to work out in Win7 and OSX but once those are baked out you will see some ISVs switch over.
How much it is embraced in Linuxland doesn’t even matter. There is nothing else on the horizon when it comes to cross-platform development.
If you’re looking at it from that point of view then you’re going to find yourself in troll territory pretty quickly one way or the other.
Do you enjoy copying and pasting code from libegg, libsexy or anything else directly into your applications as you try and solve dependency hell? Hint, no one feels the need to do that with Qt. Would you like cross-platform applications to work? Do you enjoy using half a dozen different libraries in your applications besides GTK that all look and program differently? Do you really think that has ever been a good idea?
If you can’t glean some of the avantages from the above list then there’s little that can be done for you.
What kind of applications do you work on would be a good place to start. Anyone I have known who has ever done .Net, Cocoa, Qt or even MFC programming and has looked at GTK+ have said “If that’s Linux development then no wonder it has no applications. I’m not going to write them”.
You’ve probably been doing GTK programming for two long. Ask some Windows and Mac developers what they think because they’re who the Linux desktop needs to grab.
Edited 2010-10-21 16:47 UTC
AFAIK, Qt Creator, the IDE, code editor, form designer and debugger, a true OO (primarily C++) paradigm, nice Python support, the clean abstraction layer isolation from the underlying OS that Qt provides, the extensive documentation provided for Qt, and the ability to easily support a wide set of target platforms ARE the main things that you are missing out on.
This site might be able to shed a little light on it for you:
http://www.wikivs.com/wiki/GTK_vs_Qt
It might be a little behind the very latest developments, but it seems to address your question reasonably well.
The nicest thing about QT is that it’s one framework, one coding style, one set of APIs, one environment, one dependency.
Trying to write a GTK+/GNOME app can lead to multiple coding styles, multiple API styles, tonnes of dependencies, and so on.
It’s the different between using an IDE for coding, and using a mishmash of editors and command-line tools.
Not sure it’s a good comparison. In some cases (e.g. when you really need fine-grained control on the compilation + linking process, like in kernel development), going text editor + command line is just the best option. In other (arguably most) cases, it’s IDEs which rock. One should use the right tools for the right job.
On the other hand, I can’t think of a situation where tons of dependencies with various coding styles could be a good thing.
Edited 2010-10-21 17:51 UTC
ROTFL. I had a good chuckle reading that.
Well done. Desktops that want to get anywhere need to grab developers and help them produce applications with real functionality. It’s a little late to save Ubuntu and Canonical, but what the hell?
He also draws parallels between Qt and their objectives – Arm and multi-architecture support as well as cross-platform support.
He’s going to go straight to hell for being so pragmatic and we’ll never hear from him again!
Autodesk are taking Maya all QT, and the company I work at couldn’t be sure of the license situation, so felt they had to buy a development license to develop QT Maya UIs. I don’t believe they had to, as QT could be used LGPL, and we aren’t talking about software that is released, its tools to help internal Maya artists. As it was decided we had to buy development license to use QT, there was the normal BS about do we really need it bought, can’t we just not use QT, etc etc. In the end QT is now bought and used, but it was a faff. One that wouldn’t have happened if it wasn’t dual license. Keep it simple, use one license. Free or not free, no if’s or but’s.
It’s simple: someone has to pay the development.
If someone wants to share their code, license it free, that’s ok.
If someone wants to take advantages of free/libre software… but deny this to others… support Qt at least.
It’s 2010, Qt is under LGPL. It’s perfectly okay to use Qt with closed source software without paying anyone.
See http://qt.nokia.com/products/licensing/
Ok. Now what?
With commercial license, you can ship your own modified version of Qt without disclosing your modifications. Most users don’t modify Qt.
Others do, and want to deny people the modified code and that’s why that license exist. Let them support Qt at least.
Is it really so hard to understand?
If you use QT to create an app that you sell, then you need the commercial QT license.
If you use QT to create apps that are only used internally (never distributed outside the company, never sold to anyone, etc), then you use the LGPL license.
If you use QT to create an app that you give away, you use the LGPL license.
Edited 2010-10-24 18:53 UTC
This is incorrect. You can use LGPL’d code in paid applications without disclosing the source code. That’s the point of LGPL, as opposed to GPL.
Off the top of my head, the only ones needing commercial license are people that need to statically link to Qt for whatever reason (deploying paid apps on iPhone perhaps?). Just forget that the commercial license exists and you’ll be fine.
Where did I say anything about source code?
If you sell a QT-based app, you need the commercial license.
If you don’t sell it, you don’t need the commercial license.
And, if you are a commercial company, but don’t release your software to anyone, using them internally, then you don’t need the commercial license.
No you don’t. It’s normal LGPL license like with Gtk+, look it up.
You’re right. Sometimes people confuses this. A program can be GPL and be “sold”. A program can be LGPL and be “sold”.
Edited 2010-10-24 23:14 UTC