I am nostalgic for the days of KDE (1999-2000 ish) when we believed Linux on the desktop would happen for real, and also believed KDE would take the flag. Gnome was so obviously clunky and bad, KDE felt like a breeze and reasonably feature complete.
Since then, KDE has evolved into maybe the best API interface ever for desktop programming, but the most confusing experience possible for actual users. (This may not be true anymore, but KDE lost its mindshare among users in relative terms a long time ago. I know of no-one who runs KDE on their Linux desktops. Also, desktops are specialist tools now - we have mobile phones instead and web apps for the rest.)
You are right that kde lost a lot of mindshare, but these days it is really good (I prefer it to the other DE options). My whole family runs kde, from running a small business to children of a wide range of ages playing games and doing school work.
I don't think computers are any more of a specialist tool now then 20 years ago, really. Mobile phones have just expanded the number of people who are able to do things like listen to digital music which used to be limited to a relatively elite minority on desktops.
Precisely 20 years ago you might be right, but the year 2000 later turned out to be that one year where mp3 piracy crossed over from still somewhat niche to utter mainstream. And before practical portable mp3 solutions, that was entirely a desktop PC experience. People who could barely type in January would have built their own PC from components by the end of that year. (Some regional shifts related to internet availability and pricing models might apply)
I've tried several KDE distros over the years and they have all been quite easy and pleasant to use, despite the occasional crash. There was nothing particularly bad about the UX. The reason it has not been successful is of course the largest Linux companies choosing deliberately to back GNOME. The initial reasons may have been legal but they stuck with GNOME despite the latter removing features during 2 to 3 transition and despite the legal situation resolving and KDE becoming better and better over the years. Corporate steering of s/w is very real though most seem to tiptoe around the matter...
I run Plasma on all my desktops (you must have anticipated this comment, hah). I avoided KDE until a couple years ago because its performance was always atrocious for me, even on high end machines. But when I gave it another go, I was blown away - this, right here, is the Premium Desktop Linux Experience(tm). And more than anything else, where it shines is its thoughtful approach to human factors. You can see that every aspect of the system has been subjected to the question "is this pleasant to use? how can we make it better?" And, wonderful relief, it's also fast and light now. Since I've instituted a Qt-first policy when choosing apps, and themed everything the same, Qt and GTK, I've had a superbly consistent look and feel as well.
KDE deserves its mindshare back - there is nothing else like it on Linux today.
In my opinion, it is faster, more light-weight, and at the same time has more features and is more customizable so you can set it up the way you want to work with. In my opinion it is the best desktop currently available on computers even ahead quite a bit compared to commercial ones.
I agree, KDE Plasma 5 is really awesome. It is fast, flexible, looks great and is by far the most stable desktop enviroment I have ever used, including all Windows versions and OSX.
The main downside is that it is buggy. This includes KDE's slow crawl toward Wayland support. I love KDE's features but accept I will be experiencing more resets with Plasma than even buggy Windows Explorer.
In hindsight it feels like KDE was fighting the last war's battles, eagerly marching on on the path towards an OOP modularity promised land, still trying to one-up Microsoft's OLE and COM long after those fell out of the hype spotlight at Redmond. I'd be surprised if there wasn't even a lot of CORBA in KDE at one point.
GNOME went for proper CORBA (in the form of Bonobo [1]), KDE preferred something non-standard but easier to work with and much more performant (what is now KParts [2] + DCOP [3]).
Bonobo has been abandoned around GNOME 2.4. KParts are still used in KDE 5 and you have probably heard of DCOP's child: D-Bus.
D-Bus is now mandatory system level software on Linux thanks to systemd. KHTML became the grandfather of practically all modern browsers except Firefox. In those terms, parts of the KDE project were extremely successful. It's a bit sad that the desktop as a whole didn't profit that much fron that success.
>D-Bus is now mandatory system level software on Linux thanks to systemd
Oh, it was mandatory before that, if you wanted a graphical desktop, or the ability to print, or Network Manager to work. Quite a lot of "magic" that doesn't obviously happen through files or sockets, happens over D-Bus.
That's correct. Initially we wanted to use corba, but quickly discovered that all that led to was complexity and performance problems. Then at the first KDE conference some people cobbled together dcop, which later morphed into dbus when Gnome also gave up on corba.
I dropped Linux in favor of IRIX on the desktop, because I found GNOME clunky and KDE a Windows ripoff, and ran that until I could get a Mac. When I got the Mac, despite being new, it was so slow that I installed Linux and WindowMaker on it instead. I soon broke the Mac, and got a cheap ThinkPad and ran Windows until I could afford a Mac again. I've had a Mac since 2008 now. I'd occasionally play with Linux, but especially once Unity appeared and perverted everyone's expectations of what Linux looked like, I thought the war was lost.
A couple years back, I decided to try out Plasma. Ho lee schitt. Plasma is good. Not as good as macOS, but Linux-good.
>but the most confusing experience possible for actual users
What do you mean? I think KDE is not confusing at all, you have the bottom taskbar, you have the start menu you alt+tab betwen applications. The only complaints similar to yours are from people that dislike the Settings section, there is a reason that section is complex and that is the Linux desktop is complex, there are many parts like(Qt,GTK, window manager, shell etc) but you could always have a distribution hide the settings by default and provide a KDE for newbs with almost no options and rename Settings to KDE Tweaks and you install the features from internet or hack plasmoids to add or remove paddings and features.
"Could" have, is the key. There is no push from the project itself. I'm not saying there needs to be, but I think KDE lost millions of users because of it. Imagine if ElementaryOS also were the people behind Gnome, or behind KDE. THAT would be spell quality software. Alas, this is not how open source works.
KDE developers and contributors are (or were) mainly interested in features and not looks or how to remove things, I submitted fixes and patches to add things and most of the time this were welcomed(the only issue I and the community had was with a former maintaqiner of Plasma that did not want to add option to remove the Cachew thing because he had a vision and similar GNOME like bullshit, I am happy he is gone),
so I think KDE attracts this more advanced contributors and users and also GNOME people when asked to add X they will tell you to use KDE if you don't like the GNOME way, but ont he other hand you have other GNOME people demanding KDE be like GNOME,
There is an effort in KDE to fix usability issues and improve things but it is all or mainly non paid people, but if more similar contributors would be attracted we will probably get some more polish but int he end the KDE will always have all the features it's developers and current users want.
This days KDE is trying quite hard to improve the default user experience and letting the world know about these improvements. This is mostly thanks to the work of Nate Graham and his blog posts https://pointieststick.com/, but also tons of new contributors coming each week.
Nate Graham! His posts often get quoted by Phoronix (which is in my RSS feeds). I love reading them even though I don't use KDE myself (right now; in the past I ran KDE 1/2/3 on Linux and KDE 2 on Windows).
Why? Because I like to keep a little up-to-date in Linux UI land (why I visit Phoronix). Nate Graham's weekly post are well written summaries which link to additional in-depth information if you prefer. You gave two good, relevant examples of that.
"We are making this change to encourage open-source users to quickly adopt new versions. This helps maximize the feedback we can get form the community and to emphasize the commercial support available to those with longer product life cycles that rely on a specific Qt version."
That's not correct. Me and many other Qt developers known to me still use older versions like Qt 4.8 or 5.4 without any need to upgrade. Upgrading causes a lot of effort and risks. If you don't depend on the new new feature (e.g. all of my projects would still work with Qt 4.4) why should you spend that effort?
Applications I've written using Qt twenty years ago still run with Qt 4.4 on all relevant platforms (Windows, Linux, even MacOS under Darwin) without any need for a change. As long as the old Qt version compiles on a specific OS version, there is no need to change and no one has to spend time for maintenance of the Qt version.
I go the other way round. The project should not depend on stuff only available with the new new version of the library. Even if I use Qt 5.4 or 5.9 on some projects most of it would still run on Qt 4.4. And these are not only open source spare time projects.
Well, maybe if you have implemented a server in Qt which is accessible to open internet, such as PHP in your example. 99% of the Qt applications I'm aware of are desktop or "embedded". I'm working with Qt since 20 years now and had never a security issue or a known vulnerability relevant to my projects.
WebKit is a web client library. I'm not even sure why a Qt developer would use it. That's among the first things I delete before compiling the Qt 4.x framework. OpenSSL is yet another third party library which can easily be replaced if need be without affecting Qt. And of course each application is a security risk, but definitely a smaller one than the user in front of the screen.
Library providers make this really, really hard though. They should do what used to be common practice -- separate security updates from feature updates, so that applications relying on the library don't have to be on the total upgrade treadmill.
> As for Krita, we’re using Qt 5.12 for our binaries because we carry a lot of patches that would need porting to Qt 5.13 or 5.14 and because Qt 5.13 turned out to be very, very buggy. For Krita, using a stable version of Qt that gets bug fixes is pretty important, and that will be a problem, because we will lose access to those versions.
Yeah, and I imagine this is only going to get worse from now on. The Qt Company now have much less incentive to make the open source versions reliable and usable, because their commercial customers aren't relying on that code anymore, and something of a financial incentive to make them unsuitable for anything except developing Qt itself in order to force people onto the commercial packages.
Commercial customers expect a stable version to use eventually. They also are interested in some of the new features that come with version next and so will update once in a while.
Some commercial customers stick to LTS releases, but not all do.
Where’s the logic in your statement? Say I’m an open source developer writing a Qt app. I have less time to wrangle with updates and api breakage than a company with full-time Qt developers working on their products.
The way I read it patches for the LTS versions stop being available to open source consumers when the next minor release occurs. That means open source Qt applications are forced to deal with all the new bugs that come with a new Qt release much more regularly, saving the commercial customers the hassle. That is exactly why they did this, they even say so in the announcement. That makes Qt a lot less attractive to me.
That's exactly the reason why free software should never rely on the benevolence of a for-profit company - or at least not only on their benevolence, and not for too long - because that risks creating a single point-of-failure.
That's exactly the reason why I have favoured GTK-based environments over KDE, even though I acknowledge that the API provided by Qt is probably the best I've happened to work with. GTK is owned by the community, and I know that as long as there's a passionate developer out there working on it the project is alive. When it comes to a product owned by Trolltech/Nokia/Qt Company...well, I can't be that sure.
The history of computing is already full of examples of open source projects that either died or have undergone complex forks and transition periods because the company behind them decided to pull the plug, or go for a different business model, or they went from being community-owned to being business-owned. As open source software is more and more commoditised, and unlike its counterparts it's expected to just build and run anywhere, without all the business fluff and hysteria around, we can't afford to let that happen.
However, purely community-owned open source software succumbs to the tragedy of commons on the long run - but that's a comment for another post.
This looks like a rather general remark to me, not specifically related to Qt. I don't think your argument is valid for Qt. Or do you have any representative evidence? Do you actually use Qt in your own projects at all?
You might be right in general, but this isn't a good example. Even if the Qt company was a non-profit owned by the community they might have decided on the same course of action.
But why is this an issue? The source code is available under GPL and LGPL regardless what the company does. If they would decide to no longer open source their fixes or new releases the community has still the source of the last release and can continue to maintain and develop it. There are several large open source projects which are driven by a large community; so even if the Qt Company would no longer maintain Qt (today about 50% of the commits seem to come from the community already) then others would I'm sure.
Currently I mostly see an issue in the fact that an open source developer contributing to the Qt repository run by the Qt Company signs (by action of checkin) a contributor agreement which lets the Qt company use the contributions of the developer commercially and file a law suite based on code provided by the open source developer. If there was a Qt fork independently managed by the Qt Company (e.g. on Github) people could contribute without this issue.
GTK environments (IE gnome) owe at least as much to corporations, perhaps more so. In theory GTK is community owned, but in practice it is big companies calling the shots.
I recently(about 3 months ago) started using Qt while learning C++ and I'm working on a desktop App I'm excited about. Seeing this...makes me think the future of Qt for non-commercial projects is rather bleak. Should I consider porting the App to some other API/framework? This is very sad news for me, as I was JUST starting to love Qt as an API for GUI applications. I don't want to sound dramatic, but I'm borderline freaking out guys.
> makes me think the future of Qt for non-commercial projects is rather bleak
No reason for that. Qt is available under LGPL and GPL. This cannot be changed retroactively and even today a large fraction of the commits comes from the community. There is no reason to believe that this will change.
Qt is used by so many projects that there will always be someone to provide the necessary patches. But it doesn't need that many patches because the code is already so mature and proven. I have several projects that are still based on Qt 4.4 or 4.8, for which there have been no patches for a long time. If something doesn't work well, I usually find a workaround without changing Qt.
>> it’s inevitable that Qt 5.15 will be forked into a community edition that gets maintained, hopefully not just by KDE people, but by everyone who needs a stable, LGPL licenced release of Qt5 for years to come
Right, I'll be happy to support that, if it's in a separate repository not subject to the Qt contributor license agreement.
Do any of the distributions depend on these binaries in the first place? It sounds like a non-issue to me. Don't all popular distros build all their packages from source anyway where possible?
Fair question. The desktop is still around. As long as plain old laptops or desktop machines are required (which is still a high percentage of computers) and there are developer who want to write lean platform independend applications, Qt has a good chance to being considered. The embedded market is very attractive for Qt. Actually it is also very suited for server side applications and supported async style long before Node.js was invented. The mobile market is likely lost though, and technologies like Dart/Flutter will also go towards the desktop and already support web development.
Qt is legally obligated to license QT versions under GPL and LGPLv3. They can't change that and there is no need for them to do so. This means that Qt developers work for open source at the end.
It's good that open source developers take over maintaining open source versions from Qt. You can still make commercial apps without buying Qt license just as before.
At the same time Qt business model, customers and direction it takes the software have little to nothing to do with open source software. People visiting Qt site get confused because they assumed that Qt Company supports them and expected directions of how to do stuff with free licenses.
I have a commercial qt license (paid for by my job). What is stopping me from downloading the latest QT LTS release and uploading it to my distros package system? I'm not clear if anything actually stops this.
The law, presumably. You need a license to re-distribute the Qt binaries, because you are not the copyright holder of them. You may have access to use them yourself, for your job, but you do not own the IP nor do _you_ have a license to re-distribute copies without royalty.
What you're proposing would be akin to borrowing copyrighted books from a library and uploading scans of those books, which would be copyright infringement.
72 comments
[ 0.33 ms ] story [ 217 ms ] threadSince then, KDE has evolved into maybe the best API interface ever for desktop programming, but the most confusing experience possible for actual users. (This may not be true anymore, but KDE lost its mindshare among users in relative terms a long time ago. I know of no-one who runs KDE on their Linux desktops. Also, desktops are specialist tools now - we have mobile phones instead and web apps for the rest.)
Yeah, I'm cranky. :)
I don't think computers are any more of a specialist tool now then 20 years ago, really. Mobile phones have just expanded the number of people who are able to do things like listen to digital music which used to be limited to a relatively elite minority on desktops.
Changes happened crazy fast in those days.
KDE deserves its mindshare back - there is nothing else like it on Linux today.
Bonobo has been abandoned around GNOME 2.4. KParts are still used in KDE 5 and you have probably heard of DCOP's child: D-Bus.
[1] https://en.wikipedia.org/wiki/Bonobo_(GNOME) [2] https://api.kde.org/frameworks/kparts/html/index.html [3] https://en.wikipedia.org/wiki/DCOP
Oh, it was mandatory before that, if you wanted a graphical desktop, or the ability to print, or Network Manager to work. Quite a lot of "magic" that doesn't obviously happen through files or sockets, happens over D-Bus.
A couple years back, I decided to try out Plasma. Ho lee schitt. Plasma is good. Not as good as macOS, but Linux-good.
What do you mean? I think KDE is not confusing at all, you have the bottom taskbar, you have the start menu you alt+tab betwen applications. The only complaints similar to yours are from people that dislike the Settings section, there is a reason that section is complex and that is the Linux desktop is complex, there are many parts like(Qt,GTK, window manager, shell etc) but you could always have a distribution hide the settings by default and provide a KDE for newbs with almost no options and rename Settings to KDE Tweaks and you install the features from internet or hack plasmoids to add or remove paddings and features.
so I think KDE attracts this more advanced contributors and users and also GNOME people when asked to add X they will tell you to use KDE if you don't like the GNOME way, but ont he other hand you have other GNOME people demanding KDE be like GNOME,
There is an effort in KDE to fix usability issues and improve things but it is all or mainly non paid people, but if more similar contributors would be attracted we will probably get some more polish but int he end the KDE will always have all the features it's developers and current users want.
Here is his roadmap for 2020: https://pointieststick.com/2020/01/01/kde-roadmap-for-2020/ and his review of the year 2019: https://pointieststick.com/2019/12/31/2019-the-year-in-revie...
Why? Because I like to keep a little up-to-date in Linux UI land (why I visit Phoronix). Nate Graham's weekly post are well written summaries which link to additional in-depth information if you prefer. You gave two good, relevant examples of that.
I run a KDE desktop exclusively...
https://www.qt.io/blog/qt-offering-changes-2020
"We are making this change to encourage open-source users to quickly adopt new versions. This helps maximize the feedback we can get form the community and to emphasize the commercial support available to those with longer product life cycles that rely on a specific Qt version."
The only people who really need LTS releases are companies that are able and [should be] willing to pay for LTS support.
If you're not willing to fulfill an invoice with 5+ digits, you don't need an LTS release.
But regardless, this is why integration testing is important.
"What will break if I update to Qt-latest?" being one click away.
If a security vulnerability is discovered, you always want to be on the latest version.
If updating requires a lot of effort and risks, the solution isn't "don't update". The solution is "fix those problems".
https://valdyas.org/fading/software/about-qt-offering-change...
You need a LTS of some kind if latest version is buggy as hell.
Some commercial customers stick to LTS releases, but not all do.
That's exactly the reason why I have favoured GTK-based environments over KDE, even though I acknowledge that the API provided by Qt is probably the best I've happened to work with. GTK is owned by the community, and I know that as long as there's a passionate developer out there working on it the project is alive. When it comes to a product owned by Trolltech/Nokia/Qt Company...well, I can't be that sure.
The history of computing is already full of examples of open source projects that either died or have undergone complex forks and transition periods because the company behind them decided to pull the plug, or go for a different business model, or they went from being community-owned to being business-owned. As open source software is more and more commoditised, and unlike its counterparts it's expected to just build and run anywhere, without all the business fluff and hysteria around, we can't afford to let that happen.
However, purely community-owned open source software succumbs to the tragedy of commons on the long run - but that's a comment for another post.
Only for-profit companies tend to actually need LTS releases. People don't.
Currently I mostly see an issue in the fact that an open source developer contributing to the Qt repository run by the Qt Company signs (by action of checkin) a contributor agreement which lets the Qt company use the contributions of the developer commercially and file a law suite based on code provided by the open source developer. If there was a Qt fork independently managed by the Qt Company (e.g. on Github) people could contribute without this issue.
If you want check out my app here it is-->https://github.com/thebigG/Tasker
No reason for that. Qt is available under LGPL and GPL. This cannot be changed retroactively and even today a large fraction of the commits comes from the community. There is no reason to believe that this will change.
Qt is used by so many projects that there will always be someone to provide the necessary patches. But it doesn't need that many patches because the code is already so mature and proven. I have several projects that are still based on Qt 4.4 or 4.8, for which there have been no patches for a long time. If something doesn't work well, I usually find a workaround without changing Qt.
>> it’s inevitable that Qt 5.15 will be forked into a community edition that gets maintained, hopefully not just by KDE people, but by everyone who needs a stable, LGPL licenced release of Qt5 for years to come
Right, I'll be happy to support that, if it's in a separate repository not subject to the Qt contributor license agreement.
Qt is legally obligated to license QT versions under GPL and LGPLv3. They can't change that and there is no need for them to do so. This means that Qt developers work for open source at the end. It's good that open source developers take over maintaining open source versions from Qt. You can still make commercial apps without buying Qt license just as before.
At the same time Qt business model, customers and direction it takes the software have little to nothing to do with open source software. People visiting Qt site get confused because they assumed that Qt Company supports them and expected directions of how to do stuff with free licenses.
The law, presumably. You need a license to re-distribute the Qt binaries, because you are not the copyright holder of them. You may have access to use them yourself, for your job, but you do not own the IP nor do _you_ have a license to re-distribute copies without royalty.
What you're proposing would be akin to borrowing copyrighted books from a library and uploading scans of those books, which would be copyright infringement.