Learning More About KDE's Plasma Next Desktop

[smitty3268]

So can you tell me who is wrong here.

Nobody is wrong, per se, but it's obvious that Qt is the far superior toolkit.

[schmalzler]

GTK provides the API needed for the DE. And people saying GTK is dying lives in ignorance. Go look how it is doing on Ohloh. They do pretty well and managed to keep 10x fewer LOCs than Qt.

Now it's you who is ignorant! GTK means Gimp Tool Kit, so if it is a service that provides an API it's for Gimp. But since Gnome now "maintains" the toolkit it probably should be renamed to gnome tool kit... Nevertheless it always was a toolkit used by many projects independent from GNOME. Forcing those projects to swap toolkit should not be seen as "triumph of freedom".
Furthermore comparing "gtk+" to "Qt" is stupid, especially if you want to argue with LOC. Compare gtk+ to qtgui and you will get more reliable numbers - here on my laptop gtk+ and qtgui need about the same time to get compiled -> ~3 minutes. If you want to compare the whole lot Qt is take in glib, glib-networking, webkit-gtk+, libxml, (is there a good gnome lib that does things qtxmlpatterns provieds?), and you still won't get the same set of features.b
And "doing pretty well" is not my impression when dealing with gtk+ bugs: I got the impression the devs are ignorant and incapable of even handling bugzilla:

https://bugzilla.gnome.org/show_bug.cgi?id=722211

The "double click vs single click" report is from august 2003!!! There are patches around for years, the devs seemed to be not interested in merging them or giving hints what should be changed there. Now, after years of disussion and adjusting the patches, the bug (amongst others) got marked as duplicate (instead of dependencies), put into one mega metabug, factually destroying years of work. Great job! And that for such a central part as the file dialog...

[interested]

Oh you are celebrating more code under Digia control and Digia CLA. Well I think I will skip that party, but sure do invite Oracle and Mark Shuttleworth.

Sure I celebrate the spread of open source software to more and more platforms, only grumpy sourpuss FOSS haters wouldn't do that.

Digia have been stellar in their support and development of Qt, you may not like them for some unknown reason, but the rest of the world seriously don't care about the negative opinions of some anonymous back biter; they work constructively by adding code, so Qt now have a very large user contribution.

"Expanding domain" is not a way to measure success or quality. Yeah it is nice you can write an app and have half working on a Blakcberry if that is how you define success. To Gnome the tool kit is nothing but a service, it is not expanded to be an all-platforms-super-CLA-thingy. GTK provides the API needed for the DE. And people saying GTK is dying lives in ignorance. Go look how it is doing on Ohloh. They do pretty well and managed to keep 10x fewer LOCs than Qt.

I think you are in deep denial of facts if you think Qt isn't a successful tool kit that just continue to gain market share and developer mind share.
Whether GTK is a good tool kit or not really doesn't matter in that discussion, since both projects have very different scopes. And among grown ups in the real world, outside the realm of childish fan-boism, it is actually easy to have the opinion that both tool kits are good, each with individual strengths and weaknesses.

[interested]

[QUOTE=Honton;402044]You fail to see the difference between single FOSS apps and suites/DEs. Having your own tool kit doesn't scale if you just provide af few apps, but if you do a DE, and you want to provide a enterprise level experience you need your own tool kit API. And this is what Gnome does right. I understand that KDE does not have the resources to do this and they already failed with services like nepomuk and partly with akonadi. The Calligra suite also failed.

http://www.ohloh.net/p/calligra

First of all, I just can't take you seriously as somebody claiming anything about "enterprise", I simply don't believe you have any real experience with it.

Secondly, KDE is going from strength to strength together with Qt; remember, Qt is infused with KDE technology. Both projects benefits from each other.

We all know KDE failed, they are losing developers and fewer (important) distributions ship KDE now. I find it pathetic that KDE's failing is ignored and Qt's CLA adventure into Blackberry land is seen as a major victory. *What is up with that "My preferred DE might be failing, but at least my preferred commercial toolkit is doing well at blackberries"??

I think your constant attacks on KDE and Qt is a sure sign on that they are succeeding; if KDE really was a failed project, why wasting any breath on it? Negative trolling is a sure sign on a projects increasing popularity, just look at the systemd discussion; same thing, lots of negative ranting against systemd, but the end, a wholesale victory for systemd.

Like it or not, KDE and Qt marches on. But what do you care or know about KDE? You don't use it anyway, so it is all just made up armchair talk from your side anyway.

[smitty3268]

Oh. You missed the part about Gnome3/GTK3 being used RHEL7. Qt would be unusable here. CLA and 10x the LOCs spells 100% no-go.

Since when do enterprise users care about any of that? The whole point of buying support through Red Hat is so their software developers fix any bugs and the enterprise company doesn't have to mess with the source code at all.

[interested]

Oh. You missed the part about Gnome3/GTK3 being used RHEL7. Qt would be unusable here. CLA and 10x the LOCs spells 100% no-go.


Oh. You missed the part about Unity8. The CLA tool kit found a new best friend in the CLA desktop. But I will give you the credit for bringing back the 90s where people really did believe that bigger tools makes superior software. You would probably find Qt better if the got more ports, more CLA, and more LOCs

As I said, I find it quite laughable that you start to dish out reasons why a particular tool kit is suited for enterprise or not, when you clearly never have been working in a position where such decisions are taken. In fact, I don't think you have ever worked in a prominent IT position at all. You just strike me as way too immature in your monomaniac denial of the facts of the world.

[smitty3268]

Is it really that hard to understand that GTK is maintainable as a tool kit for RHEL7 while Qt is not? CLA and 10x the LOC matter.

Yes, it is. That's kind of what we've been saying.

[interested]

Is it really that hard to understand that GTK is maintainable as a tool kit for RHEL7 while Qt is not? CLA and 10x the LOC matter.

Actually CLA's make software more attractive for the legal departments of large business since it ensures a clear legal ownership of the code. Remember, by contributing code to a Open Source project, you are signing away some rights like in a CLA, just in an informal manner.
CLA's were crucial tool for the Free Software Foundation (GNU) when Linux was a young OS and the GPL license still was untested by the courts. FSF still require CLA's for their projects to ensure they remain Free:

http://www.gnu.org/licenses/why-assign.html

So all Linux distros contains "CLA ware" in their core. There are good CLA's like the FSF and Qt CLA's that ensures that the contributed code will always remain under a Free license, and there are bad CLA's that enables the software to turn closed source. So everything depends on the nature of the CLA.

The main problem for CLA projects are that they make the bar higher for user contribution, which may lead to a lower developer participation. That doesn't seem to be a problem for Qt though, since such a high amount of its new code comes from independent developers.

Regarding RHEL 7, you are of course wrong again. Red Hat support Qt in all their enterprise (RHEL) releases. Here is notes from RHEL 6

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/lib-qt.html

The new RHEL 7 (beta) also have Qt, just like it also will have KDE, since this is exactly what their costumers want.

[interested]

Oh. You missed the difference between non-commercial CA and commercial CLA. Please do your home work.

Both Qt and FSF's CLA's are non-commercial. You would have known if you had actually read them, something that you obviously didn't do.

Oh. You failed to understand the difference between maintaining a tool kit and doing a lot of upstream work to shape the API and providing a package and support.

So you are saying that enterprise costumers like Oracle can pay to have it their way with the GTK+ tool kit by paying Red Hat? Snigger.

Well, you can actually buy enterprise support for Qt at the source, something you can't do for GTK+. That is why Qt actually have Fortune 500 costumers and hundred of thousands of developers. It has a wide scope and uses industry standard C++ (with variations like everyone else) and its user base just keeps on growing every year. With KDE Framework, Qt will be infused with KDE technology, something that will benefit both projects.
There is nothing wrong with GTK+, it just has a very limited scope and user base.

So sure, you are living in denial of facts. But your very presence in this Qt thread is a sure sign that both Qt and KDE are successful projects; it is facts you are unable to handle, so you must keep on trolling, and trolling and trolling. It seems that is it something you just can't control.

[zanny]

So I always love how every post involving Canonical, Ubuntu, Systemd, Qt, GTK, etc always devoles into CLA whining and bitching, but how about this:

I don't give a shit? I don't need to give a shit about CLAs to use qt as a GPL or LGPL framework. And Digia can't change the license on it for the versions I use, and won't change it on future versions because 1. It would destroy their install base and 2. KDE would be able to keep releasing it under GPL forever anyway.

So yeah, it would matter if I wanted to contribute to qt, but I could just as easily contribute to KDE and get the same result if I just include kdelibs with my projects, and they don't have a CLA.