The growing disconnect between KDE and the Qt Company
But last week, the company suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice."
There is a response
from the Qt Company that doesn't add a whole lot.
Posted Apr 9, 2020 14:26 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (28 responses)
Posted Apr 9, 2020 14:37 UTC (Thu)
by Flameeyes (guest, #51238)
[Link] (5 responses)
Posted Apr 10, 2020 5:11 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (4 responses)
Posted Apr 10, 2020 16:00 UTC (Fri)
by Flameeyes (guest, #51238)
[Link]
The article also predates LibreOffice, and more recently Glimpse. Maybe I should revisit it and see how it holds true in 2020.
Posted Apr 12, 2020 6:51 UTC (Sun)
by khagaroth (guest, #109895)
[Link] (1 responses)
Posted Apr 20, 2020 21:58 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Apr 16, 2020 15:52 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Also, not so way-back-ish, glibc got forked off to eglibc. The latter is now discontinued, but it was a success insofar as the glibc people woke up and fixed the issues that caused the fork in the first place.
Also consider LibreOffice as an eminently successful fork that has all but superseded the heap of inaction that is Apache OpenOffice.
Posted Apr 9, 2020 18:03 UTC (Thu)
by flussence (guest, #85566)
[Link] (21 responses)
Posted Apr 9, 2020 18:44 UTC (Thu)
by logang (subscriber, #127618)
[Link] (6 responses)
KDE is already one of the most disruptive pieces of software to update. If they were to rewrite everything *again*, I'd stop using it for good.
Posted Apr 9, 2020 23:25 UTC (Thu)
by luya (subscriber, #50741)
[Link] (4 responses)
Posted Apr 9, 2020 23:49 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
The current state is actually not that bad, but so much stuff is just plain unpolished.
Posted Apr 10, 2020 5:27 UTC (Fri)
by flussence (guest, #85566)
[Link] (2 responses)
Posted Apr 10, 2020 14:13 UTC (Fri)
by yodermk (guest, #3803)
[Link]
It's a shame, and maybe it's time for another peek...
Posted Apr 12, 2020 11:30 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
I had to go to Xfce to get a usable system ...
I'm currently stuck on KDE4, but all being well my new system will be up and running with Qt5/Plasma/whatever new "goodies" are now out.
SuSE was always a good supporter of KDE - hopefully if there's trouble they'll step up to the plate with a fork ...
Cheers,
Posted Apr 10, 2020 7:59 UTC (Fri)
by Duncan (guest, #6647)
[Link]
It helps a lot when you can bisect a regression down to an individual commit, as opposed to an entire version upgrade, and I've had considerably more success with my bug reports as well, even compared to when I was running the KDE pre-releases.
It helps with unwanted "new features" as well. I don't claim to be a dev, but once the specific code is pointed out by bisect to an individual commit, I can often revert or tweak it in a patch I can auto-apply at every update. I've been carrying a few such patches for years, now. I did the same thing at the ebuild level for the period Gentoo/KDE tried killing USE=-semantic-desktop (despite upstream KDE/plasma's continued support for the build option), too. Fortunately that one was relatively short lived and I didn't end up having to chose a different desktop. =:^)
Posted Apr 9, 2020 20:11 UTC (Thu)
by halla (subscriber, #14185)
[Link] (4 responses)
Posted Apr 13, 2020 16:42 UTC (Mon)
by Sesse (subscriber, #53779)
[Link] (3 responses)
Posted Apr 14, 2020 7:51 UTC (Tue)
by halla (subscriber, #14185)
[Link] (2 responses)
I started using Qt because it had Python bindings; I was able to become the maintainer of a big C++ application because Qt was as easy to use as Java. I continue to use Qt and C++ because I'm still the maintainer of that big C++ application.
But I'll never understand anyone who wants to use C++ without Qt. I'll never understand anyone who prefers the stl container classes to Qt's.
Posted Apr 17, 2020 16:50 UTC (Fri)
by zlynx (guest, #2285)
[Link] (1 responses)
I would just laugh if some developer wanted to add all of Qt as a dependency because they wanted to use a few Qt container classes. It's different if you're actually using it as a GUI library. Then it makes sense.
I've never found any general advantages to using the Qt stuff. The C++ standard capabilities are just as good. Trying to mix the two systems is stupid though, resulting in all kinds of useless copy operations.
Worst was when somebody decided to do a conversion operation between QList and std::vector. Every time the function was called. Oh sure look the unit tests with five elements work fine! Real life with 100,000 elements does NOT WORK FINE! Had to rewrite it to use templates. At least Qt does support standard iterators.
Posted Apr 17, 2020 17:49 UTC (Fri)
by halla (subscriber, #14185)
[Link]
I don't know who you are; zlynx; I don't know what you have created. But I agree that mixing std and Qt is dumb; using std is dumb.
I only know that I've maintained a big Qt-based application, Krita, with millions of users since 2004.
Posted Apr 9, 2020 21:26 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Apr 9, 2020 21:55 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Apr 9, 2020 21:31 UTC (Thu)
by fratti (guest, #105722)
[Link] (1 responses)
Posted Apr 10, 2020 13:55 UTC (Fri)
by clopez (guest, #66009)
[Link]
Posted Apr 9, 2020 23:44 UTC (Thu)
by atai (subscriber, #10977)
[Link] (4 responses)
Posted Apr 11, 2020 9:58 UTC (Sat)
by ncm (guest, #165)
[Link] (3 responses)
Apparently Q_* alternatives have long been supported, but they have not caught on with users. Stewards of a fork can make the more responsible choice by simply eliminating the bad macros, leaving the others.
But that doesn't mean they will.
Posted Apr 11, 2020 14:48 UTC (Sat)
by halla (subscriber, #14185)
[Link] (1 responses)
Posted Apr 17, 2020 16:13 UTC (Fri)
by ncm (guest, #165)
[Link]
Posted Apr 12, 2020 9:04 UTC (Sun)
by rdfm (subscriber, #50178)
[Link]
Posted Apr 9, 2020 15:12 UTC (Thu)
by codewiz (subscriber, #63050)
[Link] (3 responses)
Even after considering the recent Coronavirus dip, QTCOM is still up 200% in the last 12 months. Either the shareholders are not well informed about the grim financial outlook, or the KDE e.V. board was told a bunch of excuses.
Posted Apr 9, 2020 18:48 UTC (Thu)
by logang (subscriber, #127618)
[Link] (2 responses)
The only real link is that they could try and get cash by issuing shares. But investors obviously don't like that.
Posted Apr 9, 2020 21:28 UTC (Thu)
by fratti (guest, #105722)
[Link] (1 responses)
Their cash reserves in Q2 of 2019 were at around 10 million euros, with 2 millions in short-term interest bearing debt. As a point of comparison, in Q1/2017 they were at 5.42 million Euros in cash reserves and 6.13 million Euros of short-term interest bearing debt.[1] While I don't doubt the situation has changed significantly in 2020, I also would count on a lot of very cheap short-term loans becoming available this year as the EU finally figures out that maybe they should act sooner rather than having a few more embarrassingly public spats over north vs. south, which will lead to them making a lot of cash available.
With Qt employing 340 people, a very large fall in revenue would have to happen for them to completely wipe out their cash reserves and prevent them from taking up any further short term loans. The kind of drop in revenue that, in my opinion, wouldn't be compensated for by trying to boost sales in an economy that isn't very spend-happy right now.
What I think is more likely is that there's some miscommunication between Qt and KDE as The Qt Company is pondering what to put into their 23rd of April interim statements to investors.
Disclaimer: I am no financial expert, I just pretend to understand things while posting comments online because it's the only way I can feel like I'm smart.
Posted Apr 11, 2020 7:50 UTC (Sat)
by oldtomas (guest, #72579)
[Link]
Don't get me wrong, I keep coming back to lwn because of the outstanding articles, but also because of the outstanding community here in the comments section. But some topics seem to trigger old and atavistic reflexes like "C is soo old!", "STL!", "Gotta be Java!", "Client-server ain't type-safe!". Those are language wars, license model wars (and this toolkit question, which is at the crossroad of both).
Guess there has to be some replacement for religion ;-)
Posted Apr 9, 2020 18:56 UTC (Thu)
by yodermk (guest, #3803)
[Link] (11 responses)
1) was designed from the ground up for modern C++
Am I missing the existence of one? I'm nowhere near qualified to start or lead such a project, but I'd probably contribute to it.
Posted Apr 9, 2020 22:47 UTC (Thu)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Apr 10, 2020 6:27 UTC (Fri)
by liam (subscriber, #84133)
[Link]
Not exactly "from the ground up" but I think the intent matches.
Posted Apr 10, 2020 6:40 UTC (Fri)
by re:fi.64 (subscriber, #132628)
[Link] (1 responses)
Posted Apr 12, 2020 22:38 UTC (Sun)
by yodermk (guest, #3803)
[Link]
Posted Apr 10, 2020 15:29 UTC (Fri)
by simlo (guest, #10866)
[Link] (6 responses)
I write a lot of C++ code at my $DAYJOB and I like it a lot - but not for everything. I am more productive in Java and Python.
If Iwere to start a new GUI application, I would go for whatever good and fast applications are written in, and write the front end in that framework - and language!!! If it's typescript, learn typescript. Licenses are more important than language.
I would investigate using container like packaging (snap, flatpak kind of stuff) to distribute a client server architecture, where you can write the server backend in C++ if the performance requires it.
Posted Apr 10, 2020 19:34 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (3 responses)
So unless you have business reasons to have the frontend and backend run in separate processes, it seems like a bad idea to me.
Posted Apr 15, 2020 20:53 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
I struggle to see what you mean by this. Marshalling can be entirely type safe, or entirely unsafe, depending on how it is implemented. There are whole libraries for type-safe marshalling (usually attached to an RPC framework, which you are probably going to want anyway).
> When the backend allocates an object on behalf of the frontend, it needs to hand out some kind of token that the frontend can then use to interact with the object. But the backend has no way of knowing when the token is garbage collected in the frontend, so it doesn't know when to deallocate the object, so you effectively break the garbage collector by running the program in two separate processes.
That's the frontend's problem (it leaked a handle rather than closing it). I am not aware of a single (popular, modern) language which simultaneously lacks all of the following:
- The finally block or an analogous feature (like Go's defer).
So my conclusion is that the frontend, regardless of implementation language, should be capable of informing the backend when it is finished with an object.
Posted Apr 17, 2020 16:57 UTC (Fri)
by zlynx (guest, #2285)
[Link]
GC handles memory and that's it. Not any kind of resource handle or remote operation.
GC languages often have pretty stupid ways to handle intentionally restricting resources too. Since no one bothers tracking memory allocations in their code, it makes it pretty hard to restrict a single network request to 10 MB, for example.
Once you start using resource pools in Java, you may as well be writing C++ but with worse code.
Posted Apr 22, 2020 6:02 UTC (Wed)
by ssmith32 (subscriber, #72404)
[Link]
Standard question: see if someone thinks any language construct will guarantee a client will always be able to tell a server that it's time to release a resource...
If they say yes, they may not have much experience working with said systems. May or not matter for the job at hand, but it can be revealing.
Posted Apr 12, 2020 20:09 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
You'll find out that it's easy to make something responsive with FLTK, GTK, QT or bazillion other toolkits but anything "modern" is just plan out unusable.
Now, if you go into real "hey, that's free software so it's Ok to force user to buy $50 of additional memory/CPU/GPU just to run it"... then you actually have a choice.
Posted Apr 13, 2020 21:19 UTC (Mon)
by bovinespirit (subscriber, #88348)
[Link]
Posted Apr 10, 2020 9:14 UTC (Fri)
by mb (subscriber, #50428)
[Link] (2 responses)
This licensing change will not increase the cash flow. That is just implausible.
Posted Apr 10, 2020 14:23 UTC (Fri)
by yodermk (guest, #3803)
[Link] (1 responses)
That said, I'm unsure if I want to use Qt in the future now or not. Besides this kind of shenanigan, I'm a bit miffed at Qt's use of its MOC and its own types that duplicate so much of the C++ STL. I get that historically they had to develop that because the STL was not fully developed, but now it is.
If I were to use Qt, I would have strict separation between the GUI code and any actual data processing. That would be in pure C++.
Posted Apr 10, 2020 21:06 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
If you don't like moc, you can use Verdigris instead, at the cost of some additional boilerplate. But I don't see why you would – moc is the kind of thing that you configure once in your build system and then never think about again.
Posted Apr 10, 2020 11:33 UTC (Fri)
by clemensg (guest, #94377)
[Link] (5 responses)
Posted Apr 10, 2020 14:25 UTC (Fri)
by yodermk (guest, #3803)
[Link] (4 responses)
I agree, commercial pricing is absurd. Well, maybe not if you're really using it for all it's worth and it is your career. But not plausible if you just want a UI toolkit.
Posted Apr 10, 2020 14:55 UTC (Fri)
by lisandropm (✭ supporter ✭, #69317)
[Link] (3 responses)
Posted Apr 14, 2020 18:11 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
:-)
Cheers,
Posted Apr 14, 2020 18:28 UTC (Tue)
by lisandropm (✭ supporter ✭, #69317)
[Link] (1 responses)
Posted Apr 19, 2020 16:25 UTC (Sun)
by jospoortvliet (guest, #33164)
[Link]
It's quite hard to figure out licensing, and it often ends up being super stupidly bad for a portion of the user base, but to make it work for everyone often ends up lowering the total income significantly so you'd rather have it be unsuitable for a part of your customer base (who's money you lose out on) than fix that problem. Which then in turn can be a long term issue as small companies get bigger etc...
Pricing is a pita - I have some bad experience ;-)
Posted Apr 10, 2020 11:56 UTC (Fri)
by joib (subscriber, #8541)
[Link] (2 responses)
Hope they'll figure out something that is good for both the FOSS community and for the company.
Posted Apr 10, 2020 13:46 UTC (Fri)
by ocrete (subscriber, #107180)
[Link] (1 responses)
That said, the new Qt company seems to be doing much better than old Trolltech. They have a healthy business with companies making embedded devices and needing some kind of UI.
This whole things feels like greed. Not that they're struggling more than everyone else, but it seems like they want to maintain growth despite most of their customers not growing this year. Or at least not have their revenues fall more than their customers R&D spend.
This whole Qt licensing fiasco repeats itself in various forms throughout the history of Qt+KDE, this is exactly why GNOME exists in the first place.
Posted Apr 12, 2020 8:09 UTC (Sun)
by oak (guest, #2786)
[Link]
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
KDE got rewritten for decade it seems suffering of identity crisis. Lack of focus and an apparent tech preview for Qt Company are possibly an issue.
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
Wol
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
Oh God Oh No It Popped Up Again HELP
Oh God Oh No It Popped Up Again HELP
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
C++ GUI
2) was BSD-type licensed
C++ GUI
C++ GUI
Oh, it's lgpl 2.1, BTW.
C++ GUI
C++ GUI
C++ GUI
C++ GUI
C++ GUI
- try-with-resources or an analogous feature (like Python's with statement or C#'s IDisposable)
- Destructors (which run at a deterministic time, and should not be confused with GC-based finalizers).
- goto err;
- Something involving Monads (I'm sure that Haskell has solved this problem, I just don't think it uses any of the above solutions).
C++ GUI
C++ GUI
C++ GUI
C++ GUI
The growing disconnect between KDE and the Qt Company
The times where programs required the latest and greatest Qt release are long gone. Every Qt release in the last couple of years contains 99% of what projects need. If there's something minor missing, the project can just implement that detail or use another additional library.
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
Wol
The growing disconnect between KDE and the Qt Company
From outside Qt: well, Qt provides mostly what I need.
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company
The growing disconnect between KDE and the Qt Company