Qt Future Releases Panned To Be For "Paying Customers Only" For A Year - Qt is the framework which KDE relies on. This will kill all open source contributions to Qt.

  • 🔧 Actively working on site again.

Shoggoth

kiwifarms.net
Joined
Aug 9, 2019
source
One setback in the negotiations has been an announcement of The Qt Company in
January: https://www.qt.io/blog/qt-offering-changes-2020
They announced that LTS releases of Qt will only be available for paid license
holders. It is still unclear what this implies for contributions to Qt and for
the sharing of security fixes between the various parties (including The Qt
Company, the many Qt experts contributing, the KDE community, and Linux
distributions).

At an in-person meeting in Frankfurt on March 6, we nevertheless managed to
lay the groundwork for a possible path forward, continuing with an approach
beneficial to all sides.


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.
Emphasis mine
 
Trolltech fucking over KDE with stupid license shit?
It's like the 90s again.

The 12 months figure is interesting:
The foundation will control the rights to the Qt Free Edition and ensure that current and future releases of Qt will be available for free software development at all times. [...]

Should Troll Tech ever discontinue the Qt Free Edition for any rea- son including, but not limited to, a buy-out of Troll Tech, a merger or bankruptcy, the latest version of the Qt Free Edition will be released under the BSD license.

Furthermore, should Troll Tech cease continued development of Qt, as assessed by a majority of the KDE Free Qt Foundation, and not release a new version at least every 12 months, the Foundation has the right to release the Qt Free Edition under the BSD License.
 
Oh no! Not QT!
Not that slow bloated POS which started the whole trend of "Hey guys, why have a clean naitive UI when we can just use a fucking web browser?"

Good riddance. No more installing 15gb of development libraries MINIMUM.
 
Please explain? Never bothered to check how Qt works.
Instead of directly using the host platform's naitive UI, QT opens up a window and RENDERS HTML (Well, at least the new "Quick" modules do and it's more like a mix of CSS and HTML but it does use Javascript. The older widget setup is similarly faked though and again isn't drawn using the host OS's naitive APIs).
 
Instead of directly using the host platform's naitive UI, QT opens up a window and RENDERS HTML (Well, at least the new "Quick" modules do and it's more like a mix of CSS and HTML but it does use Javascript. The older widget setup is similarly faked though and again isn't drawn using the host OS's naitive APIs).
QML is a completely optional part of Qt. It's not really a web browser and they certainly didn't start the trend.
Microsoft's WPF predates it and is pretty much the same thing.
 
QML is a completely optional part of Qt. It's not really a web browser and they certainly didn't start the trend.
Microsoft's WPF predates it and is pretty much the same thing.
Honestly, Microsoft being behind this stupid trend makes too much sense.

I'd also consider Adobe after they started using flash as UI since CS4 but that's a web technology not a browser in itself.
 
  • Agree
Reactions: uncleShitHeel
Honestly, Microsoft being behind this stupid trend makes too much sense.

I'd also consider Adobe after they started using flash as UI since CS4 but that's a web technology not a browser in itself.

Is a powerful abstraction that bad? Rendering UI elements with a markup language isn't much different from a game engine using a scripting language. It actually helps people get work done, helps standardize how UI should be made and splits up the work between larger teams with design guys not having to know much about how a UI actually works to get their work done. What do you care about more, your OCD for how an application should be written or the application existing in the first place?
I don't really get people's antagonism over abstractions. People and computers don't mix, to use them efficiently we need to get as far away from the metal as possible. That's not really philosophy, it's how the world is working right now. It's not an accident, it's natural progression.
 
Is a powerful abstraction that bad? Rendering UI elements with a markup language isn't much different from a game engine using a scripting language. It actually helps people get work done, helps standardize how UI should be made and splits up the work between larger teams with design guys not having to know much about how a UI actually works to get their work done. What do you care about more, your OCD for how an application should be written or the application existing in the first place?
I don't really get people's antagonism over abstractions. People and computers don't mix, to use them efficiently we need to get as far away from the metal as possible. That's not really philosophy, it's how the world is working right now. It's not an accident, it's natural progression.
The problem is that it takes up shitloads of memory and processing power for what should be a simple operation.
The web is already slower than the flash era and running multiple instances of it just to display some simple 2D GUI is overkill. Think about how resource intensive applications like chrome, discord and slack etc. are getting.

If you wanted something simple for non-programmers you could just shove in LUA and be done with it (and that's IF you don't want to use the many tools for designing GUIs for non programmers in applications like Visual Studio). I don't see how that's more complicated than HTML, CSS and Javascript.
 
I don't really get people's antagonism over abstractions.
Abstraction:
Hardware - HAL/OS - Programming language - Graphics library - drawCircle()

Exceptionalism:
Hardware - HAL/OS - Programming language - Graphics library - platform whose complexity rivals most operating systems - JavaScript - node - ten million additional JS libraries - XML - SVG - CSS - drawCircle() // FIXME: this doesn't work on IE 7.x
 
The problem is that it takes up shitloads of memory and processing power for what should be a simple operation.
The web is already slower than the flash era and running multiple instances of it just to display some simple 2D GUI is overkill. Think about how resource intensive applications like chrome, discord and slack etc. are getting.

If you wanted something simple for non-programmers you could just shove in LUA and be done with it (and that's IF you don't want to use the many tools for designing GUIs for non programmers in applications like Visual Studio). I don't see how that's more complicated than HTML, CSS and Javascript.

The thing about Electron is it's, again, a necessary thing. It enables developers to make a single application for both web and all major desktop OSes. It's what Java always wanted to be if it didn't fail at that spectacularly. Software development is prohibitively complicated and time-consuming, I think even after 70 years of people learning that the hard way, people still don't seem to appreciate how software takes many talented man-hours to make, and it's only getting ever more complex as software is expected to simply do more things. No matter how big the company is, it's got a limited amount of employees, time and money. Companies, especially Microsoft have to strategize and make appropriate abstractions to both help themselves make software and help their customers make software for their platforms.
It's fair to say it's an unfortunate state of affairs that everything needs to be made on top of HTML, CSS and JS. It's all just kind of a fungus that sporadically grew and nobody really planned any of this out. But there are great strides by pretty much every massive IT corporation to optimize the entire stack and even trying to replace parts of it, like with WebAssembly. There's actually quite a few projects to make standalone desktop runtimes for WASM.
Plus, this doesn't really affect the average user. I don't know what your situation is, but the average well-behaved Electron app uses, like, 300MB RAM, maybe less. Most people have 8 or 16GB RAM, it's plenty of space for whatever various applications they use daily. I mean I've got a ton of shit open and I'm doing fine, I hit the page file every now and then but it's nothing too dramatic.

Abstraction:
Hardware - HAL/OS - Programming language - Graphics library - drawCircle()

Exceptionalism:
Hardware - HAL/OS - Programming language - Graphics library - platform whose complexity rivals most operating systems - JavaScript - node - ten million additional JS libraries - XML - SVG - CSS - drawCircle() // FIXME: this doesn't work on IE 7.x

That sort of contradicts the argument I made about scripting languages. Software teams aren't made solely of programmers, there are just as many designers who's specialties are design, not engineering. They need a friendly human abstraction to help them contribute to the project and do their job. Unless you feel like spending an ungodly amount of money and time to train them on your system.
 
That sort of contradicts the argument I made about scripting languages. Software teams aren't made solely of programmers, there are just as many designers who's specialties are design, not engineering. They need a friendly human abstraction to help them contribute to the project and do their job.
I'm not arguing against easy tools for people to do layout. I'm arguing against ridiculously bad tools like Electron.
It's easier to make a UI in a classic RAD than it is with Electron.
 
I'm not arguing against easy tools for people to do layout. I'm arguing against ridiculously bad tools like Electron.
It's easier to make a UI in a classic RAD than it is with Electron.

Well the point of Electron isn't about being just easy, it's about one application that works everywhere.
Electron isn't the perfect execution of the idea, but really the only way to feasibly achieve that is to create a runtime with it's own GUI framework and JIT compiler and port that runtime to as many systems as possible. Which is what a web browser is, especially one that supports WebAssembly or raw JavaScript AST. And since the web is a standard, may as well just go with that anyway.
 
Then use Java, it runs on more platforms than Electron.

I was going to say that something like Java would be a better alternative. Actually I thought .NET was sort of doing that? I think Blazor might be that. I'm not sure, I haven't kept up with that project too much, despite me being a C# dev.

That said, are you legit asking to bring back Java applets? Cuz this shit needs to work in browsers and the desktop.
 
Back