The KDE Manifesto

cannedfish — Tue, 23 Oct 2012 17:55:54 +0000

Thank you for the detailed explanation Duncan. The things you're saying really gives hope. I'll take a closer look at KDE 5.

The KDE Manifesto

Duncan — Fri, 19 Oct 2012 02:31:33 +0000

Like jospoortvliet I was somewhat confused by where you were headed. It sounds as if you have a real dislike of QT, that may or may not be warranted, but isn't explained here.

Some factors to consider:

1) Qt3 as such is dead. Support had ended before kde4, and by now it's certainly very bit-rotted and only becoming more so. Therefore it wasn't a viable base going forward.

(The trinity project continues to maintain kde3 but even there, they're porting to qt4, because qt3 is simply too much to maintain indefinitely with the resources they have, and will only become more difficult to build and run on modern systems, current gcc, glibc, etc, as time goes on, not even considering security vulns, etc, as at some point the obscureness of the platform becomes a definite advantage, there.)

Plus of course qt3/kde3 came of age when multi-core and the parallelism it brings weren't issues; clock-rates were still king of the Moore's law hill. To the extent that qt3 threading flexibility was limited, they'll look ever more anachronistic as time and Moore's law march on.

2) I too have my disagreements with kde4 (tho I continue to run it, built with USE=-semantic-desktop, etc, on gentoo, thus limiting the damage), but yours is the first post I've seen that seems to conflate kde4's problems with the switch to qt4. Kde4 definitely DID have issues early on with follow-ons continuing today and kde continues to suffer the consequences, but from my perspective anyway, few of those have anything directly to do with qt, except in the timing of the poor choices made. Had qt3 continued to be the going thing, kde would have likely eventually made many of the same poor choices with a new kde at some point before now, chasing after new features at the expense of compatibility and breaking "just works" reliability, insisting that the new version was ready for normal use while in fact it was still alpha as major features weren't yet available on the new version (feature-incomplete being a primary definition of alpha), compounding that several times over by dropping support for their old and actually /working/ version, even after a very high visibility promise to continue support "as long as there are users", etc.

If that's your complaint against kde4, then I absolutely agree, but it has little relation to kde4 being based on qt4, except as I said due to timing. It would have been perfectly doable to first port the existing kde3 from qt3 to qt4 (as trinity is doing), THEN go after all these great new features with a feature compatibility dropping (if felt-necessary) version bump, after the qt4 port of existing working functionality was done, should they still think the new features worthwhile. Alternatively, as some of the new features, particularly semantic-desktop related, were implemented with money from a grant (with from what I've read kde4's semantic-desktop features apparently being the only continuing use of what was developed, everything else was apparently dropped when the grant ran out and no further money appeared), those features could have been implemented as additional functionality on the continued porting, while keeping existing functionality in place.

Unfortunately, that's not the choices that were made, but again, that would seem to be a kde problem directly, not specifically related to the dependency upgrade to qt4.

3) Qt's days as a generally commercial product that happens to have code available as well, appear to be over.

A lot has happened since the qt3/qt4 bump era. Trolltech's long gone and Nokia's at least well on its way to divesting itself of ownership interest. (I'm not up on whether the legal deal is finalized and how many remaining qt engineers or what qt-project hosting may remain at Nokia, but whatever remains is obviously wrapup.)

Meanwhile, Nokia did setup a functional qt FLOSS community, and in general "set qt free". Qt's a community project now, with some corporate backing yes, but it's no longer a corporate project, albeit one with open source code. Those days are gone. (Support for existing commercial contracts and etc was handed off to... I've forgotten the name, and they are of course free to sell additional contracts, but qt-community-wise, it's peer-among-peers, now.)

4) As a result of all that, going forward, qt5 is now a community project, and kde's taking advantage of that to migrate a lot of functionality that was previously in kdelibs and other low-level kde packages, back when they qt was corporate-controlled and they couldn't get it in there, into qt itself, where other projects can use it without having to depend on kdelibs, etc, or otherwise become kde projects instead of simply qt projects.

Further, the qt modularization that began with qt4 is increasing in qt5, and with qt5, instead of depending on some huge qt5 package (tho some distros split qt4 to some degree as it modularized, it remained a monolithic source tarball with heavy interdependencies), the idea is to allow qt-based apps to depend on only the qt5 components they use, which will likely be packaged separately in qt5. (They split the qt5 beta in half, qt5-essentials, including qt-core, qt-gui, qt-qml, qt-webkit, etc, and qt-addons, with qt-dbus, qt-3d, qt-opengl, etc; there's indications that at least addons will be individually available, later, but I'm not sure about essentials.) Thus, devs won't have to depend on all of qt5 including the new kde-contributed modules if they don't use them all, they should be able to pick the ones they use and depend on (and for closed source apps perhaps link to statically or ship) them directly.

As for kde5/kde-frameworks, it is said to be more modular as well, and I know even with current kde4, they've already broken up many of the formerly monolithic tarballs such as kdegraphics, kdegames, etc, into individual package tarballs, with 4.8 more modular than 4.7, and 4.9 more modular than 4.8.

Meanwhile, the stated goal for kde5/frameworks in addition to modulization, is to remain generally app-space compatible with kde4, unlike the kde3/kde4 bump, allowing kde5 apps to function and integrate as well on a kde4 desktop as on kde5, and similarly, kde4 apps to function and integrate as well on a kde5 desktop as on kde4. They do NOT intend kde5 to break existing working kde4, and in fact, with the fuller modularization supporting it, from what I've read (and I've read specific statements to this effect), fully expect users to be able to pick and choose apps from both (as well as independent qt4/5 apps, gtk-based apps, etc), and migrate app by app to the new kde5/-frameworks versions as the individual kde5 apps are mature and functional enough (in the USER's judgement) to do so.

While I've /not/ specifically seen this mentioned, it's also likely with the new modularization, that people will be able to choose, for instance, a generally kde5/-frameworks desktop, but substitute, for instance, razor-qt (or whatever else, but razor-qt, being qt-based, will likely integrate somewhat better) in place of plasma as the actual desktop, if they wish. With the fuller modularization, razor-qt may thus become a fully supported and viable alternative desktop for kde, much like plasma-desktop vs. plasma-netbook today, but totally plasma independent, for those that dislike/distrust plasma in any form. (Not to say I could blame anyone for such a distrust, given that plasma stability issues and the like were a big early-kde4 problem, sort of to be expected given it was a rather large new app with extremely prominent functionality, but kde's insistence that kde4 including the still new and immature plasma was NOT broken and was ready for ordinary use compounded by their dropping of support for the actually still working kde3 thereby giving both distros and their users little choice didn't help matters any!)

As part of that modularization, I'm definitely hoping kde5/frameworks de-emphasizes the semantic-desktop stuff, which as I said, I'm building without here on gentoo with kde4, tho turning off that option does break certain konqueror/dolphin functionality (the info tab of file properties, for instance, kde3 used to show stuff like id3tag info, image comment fields, etc, but that was ripped out and replaced by semantic-desktop functionality in kde4, so without semantic-desktop, it's just a blank tab), etc. One would hope that a more modular kde-frameworks doesn't make the assumption that semantic-desktop is available, and thus has alternatives available to provide the kde3 level of information at least, if not the full "semantic-desktop" experience. Or, in worst-case, without the assumption of semantic-desktop, they could simply not provide that tab at all, if the semantic-desktop modules aren't available, instead of having a useless blank tab due to an assumption which isn't valid if people have actually taken them up on the provided option to build without semantic-desktop, as is the case with kde4.

So at least without further support (as I said, it was difficult to see where you were coming from with that comment, so maybe the factors I've addressed above had little to do with what you had in mind), it would seem that your blame of qt4 for the mess of particularly early kde4, is a canard, invalid. Yes, some kde4 choices were mistakes, HUGE mistakes, but I believe them to be squarely kde4 mistakes, having little to do with the fact that kde happens to depend on qt, and that had qt3 continued to be supported and kde4 came out based on it, the same unfortunate mistakes would have been very likely, because that's just where the kde devs were at, and the choices they made, at that point.

And "things", everything, the world as a whole including qt and kde, are different now (and qt's not the primarily commercial product it once was). Both kde and qt are so changed that what happened with kde4 doesn't seem likely again. Never-the-less, kde's dependency on qt isn't going away. Quite the reverse in fact. It's getting stronger and integration with qt closer, because with qt now a community project, that's actually possible.

Duncan

The KDE Manifesto

cannedfish — Sat, 13 Oct 2012 08:34:15 +0000

First of all my comments are highly subjective don't take them too seriously.
KDE could (in theory) continue using Qt 3. So it's not like its mandatory to instantly switch or even number releases according to new Qt major releases.
While you're right that KDE is more than Plasma or Nepomuk, they are indeed the most influencing parts of the desktop (being visible part of, crashing or painfully slowing the experience). So if you excuse me, KDE comes down to Plasma and Nepomuk in my subjective opinion. And for the rest of the applications I'm afraid I personally consider only the Digikam as important. That's one of the major problems too. It seems KDE as a platform is not very essential for me.
Contributing to Qt is very nice and respectable but I don't think it will directly translate to making a good desktop.
My whole point is free software can not and should not follow a commercial product too closely, unless it's a commercial product of someone too. Sudden changes is what making our ecosystem worse because free software is all about polish and improvement not about rewrites and dumping working code to trash.

The KDE Manifesto

mathstuf — Fri, 12 Oct 2012 20:03:16 +0000

> the hex editor (name i forgot)

Okteta

The KDE Manifesto

jospoortvliet — Fri, 12 Oct 2012 12:06:24 +0000

first of all, what do you mean by 'blindly following every Qt release'? We use it, how can you not 'blindly follow' a dependency?

second, KDE does far more than plasma desktop, heck, for the plasma team the desktop is just one formfactor they support. Calligra, digikam, amarok, Kontact and the numerous tools from dolphin and kdevelop to konversation and the hex editor (name i forgot), those all are done under the KDE umbrella.

then there is the work on frameworks 5 where KDE plans on becoming a prominent supplier of additional Qt functionally (and continue to integrate much other code in Qt proper, we are a leading contributor to Qt).

I really do not get what it is you are trying to say.

The KDE Manifesto

filteredperception — Thu, 11 Oct 2012 03:01:10 +0000

I'll assume it was entirely coincidental (whatever that means) that this happened the same day I submitted my manifesto[2] to Vint Cerf after Dave Schroeder, a Navy Information Warfare Officer[1], gave me his email address as well as public high praise for (a draft of) my manifesto. Got an ack from Mr. Cerf later that day suggesting he'll read my draft and investigate further (as he isn't directly involved with Google Fiber)

[1]
http://news.slashdot.org/comments.pl?sid=3156485&cid=... [slashdot.org]
http://news.slashdot.org/comments.pl?sid=3156485&cid=... [slashdot.org]

[2]
http://cloudsession.com/dawg/downloads/misc/kag-draft-2k1... [cloudsession.com]
http://cloudsession.com/dawg/downloads/misc/kag-draft-2k1... [cloudsession.com]
http://cloudsession.com/dawg/downloads/misc/kag-draft-2k1... [cloudsession.com]
http://cloudsession.com/dawg/downloads/misc/kag-draft-2k1... [cloudsession.com]

The KDE Manifesto

cannedfish — Wed, 10 Oct 2012 17:08:00 +0000

After writing my above comment I thought the reason that they don't matter much is actually their own fault. They could still matter if they wanted to but they made serious mistakes and we gave up.

The KDE Manifesto

cannedfish — Wed, 10 Oct 2012 17:04:46 +0000

I hope they will stop blindly following every Qt major release and feature. Seriously with KDE 4, they gave the impression that they think improving and showcasing Qt more than users. Fortunately nowadays "Desktop Environments" don't matter as much as they used to. Real free desktop is made of Firefox, LibreOffice, Eclipse etc.

LWN: Comments on "The KDE Manifesto"

The KDE Manifesto

The KDE Manifesto

The KDE Manifesto

The KDE Manifesto

The KDE Manifesto

The KDE Manifesto

The KDE Manifesto

The KDE Manifesto