OSNews

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

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.

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.

I certainly did

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

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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

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.

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