Linked by Thom Holwerda on Wed 20th Oct 2010 22:22 UTC, submitted by vivainio
Ubuntu, Kubuntu, Xubuntu 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.
Order by: Score:
Comment by cmost
by cmost on Wed 20th Oct 2010 22:25 UTC
cmost
Member since:
2006-07-16

"Qt has a lot to offer Ubuntu..."

Funny, you wouldn't know it from the sad state of Kubuntu presently.

Reply Score: 1

RE: Comment by cmost
by lemur2 on Wed 20th Oct 2010 22:33 UTC in reply to "Comment by cmost"
lemur2 Member since:
2007-02-17

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

Reply Score: 2

RE[2]: Comment by cmost
by flynn on Wed 20th Oct 2010 23:03 UTC in reply to "RE: Comment by cmost"
flynn Member since:
2009-03-19

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.

Reply Score: 1

RE[3]: Comment by cmost
by segedunum on Thu 21st Oct 2010 17:21 UTC in reply to "RE[2]: Comment by cmost"
segedunum Member since:
2005-07-06

Yer. Just where are all those .Net applications that could be turned into cross-platform ones and run on a Linux desktop under Mono.......?

Reply Score: 3

RE[4]: Comment by cmost
by qbast on Thu 21st Oct 2010 18:07 UTC in reply to "RE[3]: Comment by cmost"
qbast Member since:
2010-02-08

Right there with all other win32 applications that got turned into 'multiplatform' by wine.

Reply Score: 1

RE[2]: Comment by cmost
by testman on Wed 20th Oct 2010 23:53 UTC in reply to "RE: Comment by cmost"
testman Member since:
2007-10-15

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

Reply Score: 2

RE[3]: Comment by cmost
by lemur2 on Thu 21st Oct 2010 00:17 UTC in reply to "RE[2]: Comment by cmost"
lemur2 Member since:
2007-02-17

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?


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.

Drivers fault or not, it's all part of a package and the package suffers for it.


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.

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


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.

Reply Score: 2

RE[4]: Comment by cmost
by ephracis on Thu 21st Oct 2010 01:06 UTC in reply to "RE[3]: Comment by cmost"
ephracis Member since:
2007-09-23

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

Reply Score: 3

RE[4]: Comment by cmost
by Calipso on Thu 21st Oct 2010 13:09 UTC in reply to "RE[3]: Comment by cmost"
Calipso Member since:
2007-03-13

I have issues with compositing and an nvidia card.

Reply Score: 1

RE[5]: Comment by cmost
by lemur2 on Thu 21st Oct 2010 13:18 UTC in reply to "RE[4]: Comment by cmost"
lemur2 Member since:
2007-02-17

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

Reply Score: 2

RE[6]: Comment by cmost
by Carewolf on Thu 21st Oct 2010 17:46 UTC in reply to "RE[5]: Comment by cmost"
Carewolf Member since:
2005-09-08

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

Reply Score: 2

RE[7]: Comment by cmost
by marcus0263 on Sat 23rd Oct 2010 16:11 UTC in reply to "RE[6]: Comment by cmost"
marcus0263 Member since:
2007-06-02

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


That is unless you want to unlock nVidia's 3D and support compositing.

With Gnome you can use the proprietary drivers and use Compiz

Reply Score: 1

RE[2]: Comment by cmost
by cmost on Thu 21st Oct 2010 00:10 UTC in reply to "RE: Comment by cmost"
cmost Member since:
2006-07-16

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

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

Reply Score: 6

RE[3]: Comment by cmost
by lemur2 on Thu 21st Oct 2010 00:27 UTC in reply to "RE[2]: Comment by cmost"
lemur2 Member since:
2007-02-17

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?


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

Reply Score: 2

RE[4]: Comment by cmost
by cmost on Thu 21st Oct 2010 01:13 UTC in reply to "RE[3]: Comment by cmost"
cmost Member since:
2006-07-16

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


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

Reply Score: 3

RE[5]: Comment by cmost
by lemur2 on Thu 21st Oct 2010 01:29 UTC in reply to "RE[4]: Comment by cmost"
lemur2 Member since:
2007-02-17

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

Reply Score: 2

RE[4]: Comment by cmost
by sorpigal on Thu 21st Oct 2010 12:39 UTC in reply to "RE[3]: Comment by cmost"
sorpigal Member since:
2005-11-02

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

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.

Reply Score: 5

RE[5]: Comment by cmost
by lemur2 on Thu 21st Oct 2010 13:06 UTC in reply to "RE[4]: Comment by cmost"
lemur2 Member since:
2007-02-17

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

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

Reply Score: 2

RE[6]: Comment by cmost
by sorpigal on Thu 21st Oct 2010 20:36 UTC in reply to "RE[5]: Comment by cmost"
sorpigal Member since:
2005-11-02

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.

Reply Score: 3

RE[7]: Comment by cmost
by lemur2 on Thu 21st Oct 2010 22:20 UTC in reply to "RE[6]: Comment by cmost"
lemur2 Member since:
2007-02-17

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.

Reply Score: 3

RE[3]: Comment by cmost
by flynn on Thu 21st Oct 2010 01:53 UTC in reply to "RE[2]: Comment by cmost"
flynn Member since:
2009-03-19

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?

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.

Reply Score: 2

RE: Comment by cmost
by orestes on Wed 20th Oct 2010 22:56 UTC in reply to "Comment by cmost"
orestes Member since:
2005-07-06

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.

Reply Score: 6

RE[2]: Comment by cmost
by ggeldenhuys on Thu 21st Oct 2010 10:59 UTC in reply to "RE: Comment by cmost"
ggeldenhuys Member since:
2006-11-13

Well said, and very true! The original article talks about Ubuntu+Qt, not Ubuntu+KDE.

Reply Score: 1

RE[3]: Comment by cmost
by segedunum on Thu 21st Oct 2010 17:22 UTC in reply to "RE[2]: Comment by cmost"
segedunum Member since:
2005-07-06

To make it work you can't just have a desktop shell running Qt applications. That just isn't going to work.

Reply Score: 2

RE[4]: Comment by cmost
by orestes on Thu 21st Oct 2010 18:06 UTC in reply to "RE[3]: Comment by cmost"
orestes Member since:
2005-07-06

Works perfectly fine for cross platform apps like Virtualbox does it not?

Reply Score: 3

RE[5]: Comment by cmost
by segedunum on Fri 22nd Oct 2010 14:03 UTC in reply to "RE[4]: Comment by cmost"
segedunum Member since:
2005-07-06

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.

Reply Score: 2

Better think before talking
by Nth_Man on Thu 21st Oct 2010 09:31 UTC in reply to "Comment by cmost"
Nth_Man Member since:
2010-05-16

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

Reply Score: 3

Zimmerman note?
by Zifre on Wed 20th Oct 2010 22:56 UTC
Zifre
Member since:
2009-10-04

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

Reply Score: 1

RE: Zimmerman note?
by Angel Blue01 on Wed 20th Oct 2010 23:30 UTC in reply to "Zimmerman note?"
Angel Blue01 Member since:
2006-11-01

I certainly did

Reply Score: 1

RE: Zimmerman note?
by thavith_osn on Thu 21st Oct 2010 10:59 UTC in reply to "Zimmerman note?"
thavith_osn Member since:
2005-07-11

I thought of Bob Dylan... Go figure...

Reply Score: 2

Comment by LB06
by LB06 on Wed 20th Oct 2010 23:44 UTC
LB06
Member since:
2005-07-06

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.

Reply Score: 10

RE: Comment by LB06
by Morty on Thu 21st Oct 2010 06:45 UTC in reply to "Comment by LB06"
Morty Member since:
2005-07-06

The community and also Ubuntu has done a great job integrating both UI toolkits.

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.

Reply Score: 10

RE[2]: Comment by LB06
by LB06 on Thu 21st Oct 2010 08:11 UTC in reply to "RE: Comment by LB06"
LB06 Member since:
2005-07-06

Ok, wasn't aware of that. Thanks for the information. But that doesn't change the outcome.

Reply Score: 2

If they do this...
by darknexus on Wed 20th Oct 2010 23:47 UTC
darknexus
Member since:
2008-07-15

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.

Reply Score: 2

v ...
by Hiev on Thu 21st Oct 2010 00:18 UTC
RE: ...
by Bringbackanonposting on Thu 21st Oct 2010 00:47 UTC in reply to "..."
Bringbackanonposting Member since:
2005-11-16

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.

Reply Score: 4

v RE[2]: ...
by Hiev on Thu 21st Oct 2010 01:07 UTC in reply to "RE: ..."
RE[3]: ...
by lemur2 on Thu 21st Oct 2010 01:18 UTC in reply to "RE[2]: ..."
lemur2 Member since:
2007-02-17

And the worse, it is controlled by Nokia, hence semi-propietary


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.

Reply Score: 7

v RE[4]: ...
by Hiev on Thu 21st Oct 2010 01:20 UTC in reply to "RE[3]: ..."
RE[5]: ...
by Drumhellar on Thu 21st Oct 2010 01:39 UTC in reply to "RE[4]: ..."
Drumhellar Member since:
2005-07-12

What part of "BTW, it was Nokia who made it LGPL. Qt wasn't LGPL before Nokia purchased it." don't you understand?

Reply Score: 8

RE[5]: ...
by lemur2 on Thu 21st Oct 2010 01:40 UTC in reply to "RE[4]: ..."
lemur2 Member since:
2007-02-17

what part of "what's gonna be the license of the next version" you didn't get?


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

Reply Score: 3

v RE[6]: ...
by Hiev on Thu 21st Oct 2010 01:49 UTC in reply to "RE[5]: ..."
RE[7]: ...
by Drumhellar on Thu 21st Oct 2010 01:57 UTC in reply to "RE[6]: ..."
Drumhellar Member since:
2005-07-12

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.

Reply Score: 10

RE[7]: ...
by lemur2 on Thu 21st Oct 2010 02:19 UTC in reply to "RE[6]: ..."
lemur2 Member since:
2007-02-17

No, you don't now for shit what's the next version is going to be, so don't speculate.


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.

Reply Score: 3

RE[7]: ...
by Lobotomik on Thu 21st Oct 2010 03:26 UTC in reply to "RE[6]: ..."
Lobotomik Member since:
2006-01-03

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.

Reply Score: 3

RE[7]: ...
by r_a_trip on Thu 21st Oct 2010 09:49 UTC in reply to "RE[6]: ..."
r_a_trip Member since:
2005-07-06

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.

Reply Score: 5

RE[6]: ...
by boudewijn on Thu 21st Oct 2010 07:38 UTC in reply to "RE[5]: ..."
boudewijn Member since:
2006-03-05

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.

Reply Score: 7

RE[5]: ...
by mart on Thu 21st Oct 2010 08:48 UTC in reply to "RE[4]: ..."
mart Member since:
2005-11-17

what part of "what's gonna be the license of the next version" you didn't get?

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

Reply Score: 3

RE[5]: ...
by mat69 on Thu 21st Oct 2010 12:48 UTC in reply to "RE[4]: ..."
mat69 Member since:
2006-03-29

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.

Reply Score: 3

RE[2]: ...
by google_ninja on Thu 21st Oct 2010 04:32 UTC in reply to "RE: ..."
google_ninja Member since:
2006-02-05

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

Reply Score: 3

RE[3]: ...
by lemur2 on Thu 21st Oct 2010 05:37 UTC in reply to "RE[2]: ..."
lemur2 Member since:
2007-02-17

It was developed primarily for windows for years, and until fairly recently, actually ran faster in linux under wine then natively.


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.

Reply Score: 2

RE: ...
by Narishma on Thu 21st Oct 2010 00:48 UTC in reply to "..."
Narishma Member since:
2005-07-06

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.

MFC is just a (horrible) C++ wrapper around the win32 API. Qt is also a wrapper around the win32 API on Windows.

Reply Score: 3

RE[2]: ...
by Timmmm on Thu 21st Oct 2010 15:16 UTC in reply to "RE: ..."
Timmmm Member since:
2006-07-25

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

Reply Score: 2

RE[3]: ...
by segedunum on Fri 22nd Oct 2010 14:05 UTC in reply to "RE[2]: ..."
segedunum Member since:
2005-07-06

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.

Reply Score: 2

RE: ...
by lemur2 on Thu 21st Oct 2010 01:10 UTC in reply to "..."
lemur2 Member since:
2007-02-17

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.


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?

Reply Score: 4

RE: ...
by Neolander on Thu 21st Oct 2010 05:13 UTC in reply to "..."
Neolander Member since:
2010-03-08

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.

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

Reply Score: 3

RE[2]: ...
by Hiev on Thu 21st Oct 2010 13:53 UTC in reply to "RE: ..."
Hiev Member since:
2005-09-27

Cocoa works on Apple platforms, .NET on MS platforms, news at eleven.

Reply Score: 2

RE[3]: ...
by lemur2 on Thu 21st Oct 2010 14:35 UTC in reply to "RE[2]: ..."
lemur2 Member since:
2007-02-17

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.

Reply Score: 2

RE[4]: ...
by Hiev on Thu 21st Oct 2010 14:43 UTC in reply to "RE[3]: ..."
Hiev Member since:
2005-09-27

And that's why it is mediocre on Linux.

Linux needs a dedicated toolkit not one that want's to be "everywhere".

Reply Score: 2

RE[5]: ...
by Nth_Man on Fri 22nd Oct 2010 18:42 UTC in reply to "RE[4]: ..."
Nth_Man Member since:
2010-05-16

And that's why it is mediocre on Linux.


That really has no logic. Qt apps are compiled for the target operating system.

Reply Score: 1

Qt Quick
by puelocesar on Thu 21st Oct 2010 00:41 UTC
puelocesar
Member since:
2008-10-30

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.

Reply Score: 3

RE: Qt Quick
by Nth_Man on Thu 21st Oct 2010 09:56 UTC in reply to "Qt Quick"
Nth_Man Member since:
2010-05-16

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

Reply Score: 2

RE[2]: Qt Quick
by puelocesar on Thu 21st Oct 2010 11:26 UTC in reply to "RE: Qt Quick"
puelocesar Member since:
2008-10-30

lol, you should see a Qt Quick hello world then:

import Qt 4.7

Text {
text: "Hello World"
}

Reply Score: 2

RE[2]: Qt Quick
by ebassi on Thu 21st Oct 2010 13:15 UTC in reply to "RE: Qt Quick"
ebassi Member since:
2006-02-28

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?

Reply Score: 1

RE[3]: Qt Quick
by segedunum on Thu 21st Oct 2010 16:32 UTC in reply to "RE[2]: Qt Quick"
segedunum Member since:
2005-07-06

Hmmmm. You do realise that those two sections of code are functionally equivalent and do the same things right?

Reply Score: 3

RE: Qt Quick
by Timmmm on Thu 21st Oct 2010 15:17 UTC in reply to "Qt Quick"
Timmmm Member since:
2006-07-25

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.

Reply Score: 2

GTK-compatibility layer
by Lennie on Thu 21st Oct 2010 00:44 UTC
Lennie
Member since:
2007-09-22

They might as well, just create a GTK-compatibility layer so all existing GTK-apps work with QT.

Reply Score: 2

RE: GTK-compatibility layer
by Elv13 on Thu 21st Oct 2010 01:14 UTC in reply to "GTK-compatibility layer"
Elv13 Member since:
2006-06-12

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.

Reply Score: 2

hugh
Member since:
2010-10-20

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

Reply Score: 3

mart Member since:
2005-11-17

... and javascript(a node.js for the desktop).


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

Reply Score: 2

I have to say it...
by mweichert on Thu 21st Oct 2010 02:27 UTC
mweichert
Member since:
2006-03-23

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.

Reply Score: 1

RE: I have to say it...
by lemur2 on Thu 21st Oct 2010 02:48 UTC in reply to "I have to say it..."
lemur2 Member since:
2007-02-17

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.

Reply Score: 6

really? vlc?
by google_ninja on Thu 21st Oct 2010 04:11 UTC
google_ninja
Member since:
2006-02-05

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.

Reply Score: 2

Good for both parties
by ndrw on Thu 21st Oct 2010 12:58 UTC
ndrw
Member since:
2009-06-30

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

Reply Score: 1

RE: Good for both parties
by siride on Sat 23rd Oct 2010 05:36 UTC in reply to "Good for both parties"
siride Member since:
2006-01-02

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.

Reply Score: 2

RE[2]: Good for both parties
by ndrw on Sun 24th Oct 2010 03:37 UTC in reply to "RE: Good for both parties"
ndrw Member since:
2009-06-30

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.

Reply Score: 1

RE[3]: Good for both parties
by vivainio on Sun 24th Oct 2010 06:44 UTC in reply to "RE[2]: Good for both parties"
vivainio Member since:
2008-12-26

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


If you like the way Gtk looks, just use QGtkStyle. It's the default when running in Gnome on Ubuntu.

Reply Score: 2

RE[4]: Good for both parties
by ndrw on Sun 24th Oct 2010 14:42 UTC in reply to "RE[3]: Good for both parties"
ndrw Member since:
2009-06-30

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.

Reply Score: 1

RE[3]: Good for both parties
by phoenix on Sun 24th Oct 2010 18:46 UTC in reply to "RE[2]: Good for both parties"
phoenix Member since:
2005-07-11

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

Reply Score: 2

Technical superiority to GTK
by tristan on Thu 21st Oct 2010 13:50 UTC
tristan
Member since:
2006-02-01

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.

Reply Score: 2

RE: Technical superiority to GTK
by lemur2 on Thu 21st Oct 2010 14:29 UTC in reply to "Technical superiority to GTK"
lemur2 Member since:
2007-02-17

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

Qt Creator is a cross-platform C++ integrated development environment which is part of the Qt SDK. It includes a visual debugger and an integrated GUI layout and forms designer.


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
Qt Creator provides support for building and running Qt applications for desktop environment (Windows, Linux, and Mac OS) and mobile devices (Symbian, Maemo, and MeeGo). Build settings allow you to quickly switch between build targets.

When you build an application for a mobile device target with a device connected to the development PC, Qt Creator generates an installation package, installs in on the device, and executes it.


Find out more here:
http://qt.gitorious.org/qt-creator/pages/FrequentlyAskedQuestions

Reply Score: 2

tristan Member since:
2006-02-01

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

Reply Score: 2

Timmmm Member since:
2006-07-25

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.

Reply Score: 9

nt_jerkface Member since:
2009-08-26

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.

Reply Score: 3

segedunum Member since:
2005-07-06

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

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?

You can find a lot of things saying "Qt is superior" without any real details about what makes it superior.

If you can't glean some of the avantages from the above list then there's little that can be done for you.

Like I said, I know quite a bit about GTK development -- I do it for a living...

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

Reply Score: 5

lemur2 Member since:
2007-02-17

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


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.

Reply Score: 2

RE: Technical superiority to GTK
by phoenix on Thu 21st Oct 2010 17:05 UTC in reply to "Technical superiority to GTK"
phoenix Member since:
2005-07-11

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?


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.

Reply Score: 5

Neolander Member since:
2010-03-08

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

Reply Score: 3

The Penny Drops........A Little?!
by segedunum on Thu 21st Oct 2010 16:52 UTC
segedunum
Member since:
2005-07-06

ROTFL. I had a good chuckle reading that.

We want to make it fast, easy and painless to develop applications for Ubuntu...

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!

Reply Score: 2

I don't like dual lience.
by jabjoe on Fri 22nd Oct 2010 15:56 UTC
jabjoe
Member since:
2009-05-06

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.

Reply Score: 1

RE: I don't like dual lience.
by Nth_Man on Fri 22nd Oct 2010 18:51 UTC in reply to "I don't like dual lience."
Nth_Man Member since:
2010-05-16

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.

Reply Score: 1

RE[2]: I don't like dual lience.
by vivainio on Sat 23rd Oct 2010 20:31 UTC in reply to "RE: I don't like dual lience."
vivainio Member since:
2008-12-26


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.

Reply Score: 2

RE[3]: I don't like dual lience.
by Nth_Man on Sun 24th Oct 2010 06:20 UTC in reply to "RE[2]: I don't like dual lience."
Nth_Man Member since:
2010-05-16
RE[4]: I don't like dual lience.
by vivainio on Sun 24th Oct 2010 06:41 UTC in reply to "RE[3]: I don't like dual lience."
vivainio Member since:
2008-12-26



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.

Reply Score: 2

RE[5]: I don't like dual lience.
by Nth_Man on Sun 24th Oct 2010 17:22 UTC in reply to "RE[4]: I don't like dual lience."
Nth_Man Member since:
2010-05-16

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.

Reply Score: 1

RE: I don't like dual lience.
by phoenix on Sun 24th Oct 2010 18:52 UTC in reply to "I don't like dual lience."
phoenix Member since:
2005-07-11

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

Reply Score: 2

RE[2]: I don't like dual lience.
by vivainio on Sun 24th Oct 2010 19:03 UTC in reply to "RE: I don't like dual lience."
vivainio Member since:
2008-12-26

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.


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.

Reply Score: 2

RE[3]: I don't like dual lience.
by phoenix on Sun 24th Oct 2010 19:06 UTC in reply to "RE[2]: I don't like dual lience."
phoenix Member since:
2005-07-11

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.

Reply Score: 2

RE[4]: I don't like dual lience.
by vivainio on Sun 24th Oct 2010 19:43 UTC in reply to "RE[3]: I don't like dual lience."
vivainio Member since:
2008-12-26

If you sell a QT-based app, you need the commercial license.

No you don't. It's normal LGPL license like with Gtk+, look it up.

Reply Score: 2

RE[5]: I don't like dual lience.
by Nth_Man on Sun 24th Oct 2010 23:11 UTC in reply to "RE[4]: I don't like dual lience."
Nth_Man Member since:
2010-05-16

"If you sell a QT-based app, you 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

Reply Score: 1