From this: http://debarshiray.wordpress.com/2012/10/06/goa-why-it-is-the-way-it-is/
“However, it is a bit more complicated than that. MeeGo (and now Ubuntu’s) SSO has a DBus daemon written using Qt. We have been down this road before, most recently with Maliit. The daemon would have had to be rewritten without Qt using GObject for it to be a part of GNOME.”
Honestly, do I need to write anything? No reasoning or explanations, just knee-jerk “it’s written in Qt, we can’t touch this”. When did this turn into a political battle? We shouldn’t working against eachother here, if someone has great technology we can use (as long as it is freely available and licensed properly, works well, etc.).
I think this is one of the reasons KDE has thrived as well as it has, even without the commercial backing that Gnome has enjoyed; less politics and more fun. I don’t think I’ve ever seen a piece of software getting denied inclusion in KDE because it had non-kosher dependencies.
The comments also have some gold, though, like this:
“But whether that means GNOME should accept Qt is not a decision that is for me or a single individual to make.”
So Gnome is now a corporate, hierarchical software organization, where individual developers have no say? What happened to meritocracies? And where the flying fuck comes thoughts like the need to “accept Qt” from?
Honestly, I like Gnome (though I haven’t used it as my main desktop in some years), I like the Gnome developers, and I think they make a lot of great technology which helps free software in general (and KDE in particular). That’s why it boggles my mind that they sometimes come with these outbursts of irrationality.
/rant
sandsmark's blog 
I sort of agree with the sentiment, but whenever I start a QT app on my ubuntu desktop there’s a noticeable lag as all the QT libraries get loaded. Of course the gnome libs are large too, but they’re already in memory and I do think this is a good argument for not relying on QT apps.
What kind of system (HW-wise) are you on? QtCore is 2.9MB here on arch, that honestly shouldn’t take much time for any modern system to load into memory. Especially now that SSDs are getting more and more prevalent.
A couple of years old amd dual core, but honestly I do usually have a virtual machine running in the background and firefox with a lot of tabs.
The reason for the lag I think is one, because those apps use more than just QtCore, and two, they have to cache a lot of small files (icons, decorations and such) which creates disk I/O even if they are already rendered and scaled. But basically this is all just speculation, I haven’t benchmarked it.
You should know that Unity is written in Qt ;-)
It is not. Only the Unity-2D was but that has now been dropped.
I think a large part of it is that accepting Qt as a dependency for such a core system would require accepting lots of duplicated functionality and would increase the amount of stuff that distributions would need to include by a very non-trivial amount (tens of megabytes). Personally, I wish the cores (basically, all the non-GUI stuff) of Qt and GTK/glib/GObject/whatever would just merge. I think that would solve this particular dilemma (although it would be a ton of work).
There is already very prevalent duplication; the most obvious example is that glib is pretty much a re-implementation of a large part of C++ (which they also use). I honestly don’t see why that is an issue, though.
GNOME already does lots of duplication with Clutter. It’s not an extension to GTK but a completely separate toolkit that requires pretty much everything to be duplicated: From simple buttons to a separate port of WebKit for integration.
How’s that different from QML vs. QWidget?
I don’t know but “Qt duplicates GTK functionality and that’s why Qt can’t become a GNOME dependency”-argument is retarded.
@targz: the topic is about relying on Qt *libs*, not apps. If you have Qt dependencies, the libs are loaded into memory, hence you have no performance issue next time.
“whenever I start a QT app on my ubuntu desktop there’s a noticeable lag as all the QT libraries get loaded” is wrong is not just one way:
1. There’s a lag on first load only; unix systems with standard settings cache the libraries (I bet you did not mean Android since there’s no GNOME on it anyway)
2. Noticable lag? what exactly – what hardware do you use? Full Qt libs is so much smaller in memory than any modern browser.
3. All Qt libraries – that’s not true, apps use selected libraries only, nothing special here.
4. Qt, not QT ;)
I think this is one of the reasons KDE has thrived as well as it has, even without the commercial backing that Gnome has enjoyed; less politics and more fun. I don’t think I’ve ever seen a piece of software getting denied inclusion in KDE because it had non-kosher dependencies.
Actually, we do this all the time in KDE, largely because of licensing issues. There was a very recent case of this discussed on the kdepim mailing list. Not sure how it was resolved, though.
There are many reasons to keep Qt and glib separate. One is that they are written in different programming languages and serve very different needs. I’m a KDE/Qt user, but I like having choices and the option to use a “lightweight” C library instead of a C++-based one makes a lot of sense in many circumstances.
It’s important to have standards, but it’s important to have several competing implementations of those standards in order to give users (and downstream developers) choices, to have a “backup” in case development stalls in one branch, and to avoid “one-size-fits all” thinking.
«Actually, we do this all the time in KDE, largely because of licensing issues. There was a very recent case of this discussed on the kdepim mailing list. Not sure how it was resolved, though.»
Yes, legal problems are another beast entirely, and not what I’m talking about at all.
«It’s important to have standards, but it’s important to have several competing implementations of those standards in order to give users (and downstream developers) choices, to have a “backup” in case development stalls in one branch, and to avoid “one-size-fits all” thinking.»
So you believe we should have, for example, another X.org implementation as well? Or another udev implementation?
Yes! We wouldn’t have Wayland, for example, if we hadn’t had the XFree86/X.org split. udev is sort of a special case as it is such a low-level software that it might almost be considered part of the operating system itself (indeed, part of udev lives in the kernel) and so the alternatives are alternatives to Linux (such as FreeBSD and so forth), rather than just to udev itself. But I definitely think it’s healthy to have multiple development streams working on these implementations.
Replying here because wordpress is retarded.
But X.org was a fork, it was not another project developed in parallel.
But I do agree with your sentiment and I don’t have a problem with this project in particular, only the reasoning they present for it.
i undestood something time ago…
everyone lives in their own beliefs so … just ignore this shit.
“When did this turn into a political battle? We shouldn’t working against eachother here, if someone has great technology we can use (as long as it is freely available and licensed properly, works well, etc.).”
Qt is not licensed and managed properly. CLA and total control placed at a single entity is “not cool”. This should not be confused with politics this is much larger than that. If you accept any dependency from varoius CLAed Single entities then youare asking for trouble. Gnome tries to solve this by doing stuff the right way. Keep it simple and say no to quick fixes.
KDE can surely do their own thingbut please do realize that Gnome does not see crazy stuff like KDEs Nokia/Digia buyout/bankrupcy mayhem. I would call Gnomes stance to more than politics its is simple pragmatism. The keep the foot out of the hornets nest. Wise chioce.
What you are talking about here is _exactly_ the kind of politics bullshit I’m tired of.
And if you want to discuss how accepting freely licensed LGPL libraries from any entity is asking for trouble, or where this made-up “mayhem” is occuring you can do it somewhere else, this is my soapbox. :P
So you are simply not accepting the risks introduced by Qt because it is your sandbox? Well then.. You ssem quite incompatable with reality. It is not surprising you sond so angry.
hunla7,
What are exactly the risks introduced by Qt? Care to explain?
What do you mean by “Qt is not licensed and managed properly” and what’s the problem with the CLA? (which is similar to the CLA that the FSF, Apache Software Foundation and others require)
Oh, and Gnome’s way? I wouldn’t call it “the right way”, “simple” or anything like that. Looks more a NIH syndrome.
FSF is not CLAing for the same reason. Qt is CLAing to sell non-free licenses. FSF is CAing to do better enforcing of the GPL in legal disputes. FSF is for freedom, Qts CLA is an instrument _against_ freedom.
Freedom is nice but it is not Gnome entire reasoning to avoid Qt. Pragmatism is the key here. They do get to avoid all the Qt rumbling and dealing with a new set of deps. This holds a much larger benefit than any claimed benefits of Qt.
You might not agree but is how most people outside KDE sees it.
@hunla7@hmamail.com: What are the risks? Please, explain them to me in detailed form. You can even use copyright and contract law terms, I’m here to learn.
AFAIK, the CLA is done to simplify relicensing and to manage several licensing models (something I find perfectly acceptable), and has nothing to do with the actual licensing of the code. If you are speaking about moral rights, no, neither Nokia nor Digia have them. The GPL deal with the actual licensing of the code, and the CLA can’t touch past versions of the code, since it doesn’t allow to alter retroactively code already licensed. So, there should be no risks for a normal user or licenser of the code.
What an interesting reading you gave me. As the part II of my post, I actually read the Qt CLA ( http://www.kde.org/community/whatiskde/QtContributionLicenseAgreement-1-1.pdf ), and it basically says that if I want to contribute to Qt:
– I must license my code under LGPL 2.1.
– I must give a sublicensable license to Nokia, to redistribute this code under a proprietary license if deemed appropiate.
– Nokia has a sublicensable license, not the actual copyright, so the Qt code remains always under LGPL 2.1.
– There is a separate contract between KDE and Nokia, regulating what happens if Nokia fails to publish the LGPL 2.1 source or fails to provide a freely licensed Qt copy: KDE has the right to publish all the code, under a BSD license.
I completely fail to see how this is “an instrument _against_ freedom”.
ITT: FUD from ignorant trolls.
Oh, if you have problems with such kinds of CLAs, GNOME better remove all dependencies to CUPS, MySQL/MariaDB, etc. because they all require signing a CLA (to allow closed source versions) to contribute.
KDE can surely do their own thingbut please do realize that Gnome does not see crazy stuff like KDEs Nokia/Digia buyout/bankrupcy mayhem.
What bankruptcy? Digia has only just bought Qt, it’s not bankrupt; no company that owned Qt has gone bankrupt.
It can be a sane architectural decision not to drag in everything and the kitchen sink as dependencies.
You may be tired of politics but politicians will never be tired to politicize us :)
If memory serves well, in the past a lot of company distributing Linux(a lot of them strongly relying on KDE) had custom closed source tools built on GTK because Qt wasn’t available as LGPL option. In general that’s one of the main reasons which lead to the current culture of GNOME – “our way or the highway”. In a lot of ways it’s changed nowadays…but still the irony is that proprietary stuff are dictating the development of FOSS related stuff :D
You know, the culture impact is strong impact and it will take time for some folks to start think logically. Nothing unusual.
Anyhow, you are touching real hornets nest here…
The NIH syndrome is honestly not the only thing that’s killing Open Source.
For a full list go here: http://bit.ly/gBOiz6
“That’s why it boggles my mind that they sometimes come with these outbursts of irrationality.”
GNOME is a _religion_. Its basis is irrational, i.e. “C++ is bad”. The outbursts of irrationality are entirely normal for an intelligent person living with the stress of supporting an ignorant viewpoint.
“it boggles my mind that _they_ sometimes come with these outbursts of irrationality.”
Avoiding unnecessary extrapolation helps. The blog post and comments your write about were all written by one single person.
I don’t want to be ironical, and I perfectly understand your rant: I’m just sad to realize that you are ranting about one sentence within the full original post, which actually explains this is not the only reason why they want to rewrite their own stuff. The post as a whole holds sense: It’s not only political and even if the author would have political reasons, he doesn’t even speak about it: it’s also very pragmatic and based upon technical reasons.
FIY I’m a GNOME user, using a Gentoo, I am also using some Qt based software, and I’m deeply bored each time a package needs the whole Qt* suite to be installed or updated because it literally takes hours (another very valid reason for *not* embeding such dependencies when you already have everything you need).
How about using a distribution which compiles Qt (and everything else) for you? There’s no point in recompiling software you aren’t actually modifying.
This is off topic, but simple answer: I do need to compile a lot of software in order to set numeours specific or exotic options that most distro don’t, for my daily job. It also handles for me multiple concurent versions of the same software on the same system. Desktop is just a bonus I recompile only once every 6 monthes.
Actually I think the author of blog post you linked to was mainly addressing the Qt code base of the daemon under the wrong assumption that GNOME would be shipping it.
As a community they probably don’t have a lot of Qt know-how and such would not ship something they can’t maintain themselves.
However, as this daemon would be an independent shared infrastructure component, e.g. like NetworkManager, it would be shipped and maintained by its own community and only used by GNOME. I would be surprised if they had any policy or desire to maintain all their dependencies themselves.
I have to admit that the first lines are surely highlighting Qt, but when you read it fully I don’t think it was the only concern.
However, your second paragraph sounds legit, I don’t know enough the GNOME community to agree or disagree about this point. But in the end, I think (and I might be wrong, I’m no expert nor contributor) that KDE and GNOME are very alike about a lot of topics: for example they both intend to be a fully featured platform which gets closer to what provides the OS (not only just a desktop but spreading down into the application stack almost reaching it, providing APIs such as rendering, audio, video etc…), case in which I understand the fact that they wouldn’t want to be dependent on a “foreign” (excuse my french) library that is supposed to occupy the same layer as their own, they’d prefer to remain dependent on something that is much more “simple” (not sure this is the right word once again).
Of course, that is just a point of view, and very subjective one, and once again, I surely do understand your rant, even if I don’t see the harm myself.
“I understand the fact that they wouldn’t want to be dependent on a “foreign” (excuse my french) library”
Not being satisfied with the library provided by Ubuntu does not invalidate the idea of sharing the daemon.
The complaint about the library using an outdated way to access D-Bus should ideally lead to the conclusion that the easiest way is to implement a new library using the most current D-Bus access method but at the same time keep the shared service component.
One of the main reasons for doing a shared service approach is to insulate against technolog choices between the participating parties. Ubuntu’s library using dbus-glib does not in any way prevent KDE from using QtDBus in their library or GNOME from using GBus in theirs.
I don’t understand something, isn’t asking every gnome shipping distribution to include qt in the cds a bit too much?
I think it’s wrong If a desktop environment includes more than 1 library that does the same.
I wouldn’t like to have gtklibs as a necessary dependence of the desktop, You say kde doesn’t reject software from other places, What things that requires gtk that are included in kde?
A service like that should be developed without either qt neither gobject, so it can be used in both environment or it should be re-implemented.
The discussion here is about QtCore, which compares to GLib, not GTK+ (that would be QtGui). A lot of stuff on a modern KDE desktop depends on GLib.
Thanks I get it now, qtcore could be included without much problems.
+1 to this blog post, I’m really fed up of GNOME’s NIH approach and of their attitudes towards interoperability. I put “attitudes” in the plural, because they are really 2 prevalent ones: one ignores interoperability entirely and wants everyone and everything to use GNOME and only GNOME, the other one defines “interoperability” as “everyone else adopts GNOME’s technologies”. Both are equally bad.
> I don’t think I’ve ever seen a piece of software getting denied inclusion in KDE because it had non-kosher dependencies.
sadly, that’s wrong: https://github.com/giddie/poppler-qt4-cairo-backend#readme
i’d so wish for that to be pulled in. i don’t care at all if it needs cairo, it just looks better, and whoever has okular installed, does not have an extremely tight disk space constraint.
Poppler is not a KDE project.