A better Qt already exists. It's called Electron.
laughs in gigabytes
You just need to download more ram.
A Better Qt Because of Open Source and KDE
11–20 of 125 posts
Re: A Better Qt Because of Open Source and KDE
#12Earlier quoted context omitted.
laughs in gigabytes
You just need to download more ram.
We've banned this account for trolling. Could you please stop creating accounts to break HN's guidelines with?
Also, please don't make accounts for every few comments you post. We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
Re: A Better Qt Because of Open Source and KDE
#13Re: A Better Qt Because of Open Source and KDE
#14It would be good for KDE to get stronger backing, but I've heard RedHat avoids backing KDE and focuses on Gnome, due to aversion¹ to contributor agreements², is that correct in that case? 1. https://opensource.com/article/19/2/cla-problems 2. https://www.qt.io/legal-contribution-agreement-qt
It all goes back to the early days of Gtk vs KDE, when Qt still had non-GPL compatible license.
Red-Hat is the biggest employer of Gtk/GNOME devs, so...
SuSE and Mandrake were historical the biggest ones that cared about KDE.
Re: A Better Qt Because of Open Source and KDE
#15A better Qt already exists. It's called Electron.
Only if you mean a better heat producing software.
Re: A Better Qt Because of Open Source and KDE
#16Re: A Better Qt Because of Open Source and KDE
#17Re: A Better Qt Because of Open Source and KDE
#18Re: A Better Qt Because of Open Source and KDE
#19A better Qt already exists. It's called Electron.
I'll bite. Define "better" here.
Not a fan of electron at all. But I think it points out the direction for the future of gui. There's a whole generation of new languages (rust, go, dart, D, ...) that wants to get into the gui-space and finding QT and GTK problematic. QT is known for "using every C++ feature", making it less than ideal for bindings. GTK is not very cross platform I think, and is criticized for beeing gnome-centric. Both toolkits are object-oriented, making them a poor fit for any language that is not. Something like mozilla's webrender could be used in a more language agnostic way (declerative, reactive), while having the support required for the gargantuan task of a graphics/toolkit backend.
Re: A Better Qt Because of Open Source and KDE
#20It would be good for KDE to get stronger backing, but I've heard RedHat avoids backing KDE and focuses on Gnome, due to aversion¹ to contributor agreements², is that correct in that case? 1. https://opensource.com/article/19/2/cla-problems 2. https://www.qt.io/legal-contribution-agreement-qt
At KDE, we don't require signing CLA to contribute, this is a requirement in our manifesto[1]. But contributor can assign their right to the KDE e.V. if they want using a Fiduciary Licensing Agreement[2]. [1]: https://manifesto.kde.org/commitments.html [2]: https://ev.kde.org/rules/fla.php
KDE itself no, but Qt requires one (second link above)?
Ironically, RedHat themselves sometimes make an exception, like the first link mentions:
> We reluctantly sign tolerable upstream project CLAs out of practical necessity.