New Qt Releases Might Now Be Restricted To Paying Customers For 12 Months

[shmerl]

Options: Fork it and make development independent? Or make another GUI framework, using Rust.

[oleid]

GTK is not an alternative and anyone who has ever tried writing a little application with both toolkits knows. There's good reasons why just about everyone but gnome is jumping off GTK, and it's not that GTK's API is so wonderful.

Really? I've programmed using both toolkits, started with GTK2 back then when it was new and created freepascal bindings. Also used Qt3, 4 and nowadays Qt5 at work. I still prefer GTK+ as its API is cleaner. And I like its C++ bindings more than Qt's C++ API.

So no, it is not everyone who thinks that way, as you claim.

[oleid]

That would be an understatement, I would say that GTK support for Windows is outright terrible compared to the competition

Chicken-egg-problem. Hardly anyone uses GTK to target windows and hardly anyone working on the toolkit cares about windows. As GTK+ is mostly founded by Linux companies. If the people wanting to target Windows with their apps would also participate in toolkit development, that might change.

Nevertheless, GTK+ works on Windows. At least I can run native GTK+ apps just fine, last time I tried. Yet, I would imagine that it is not well integrated into VisualStudio&Co.

[TemplarGR]

Really? I've programmed using both toolkits, started with GTK2 back then when it was new and created freepascal bindings. Also used Qt3, 4 and nowadays Qt5 at work. I still prefer GTK+ as its API is cleaner. And I like its C++ bindings better than Qt's C++ API.

So no, it is not everyone who thinks that way, as you claim.

I second this.

[lumks]

This sounds really bad. Most Bugs I report are Qt bugs. So now they will stay much longer in until they come down the line for KDE. In case of LTS distros this could end in 5years of waiting for simple bugfix.

On the other end, if KDE would fork, at some point it would just not be compatible with Qt-company-Qt anymore so no crossporting and that means bitrot with a smaller community.

Best road to go, would maybe be to Ask the GTK guys to push back GTK4 and do a collaboration so that after GTK4 is out, its possible to slowly port KDE to GTK4 without to much missing features on the framework side.
What do you think?

[oleid]

Options: Fork it and make development independent? Or make another GUI framework, using Rust.

Already on it. These are the (IMHO) most interesting ones:

• https://github.com/hecrj/iced
• https://github.com/xi-editor/druid

[oleid]

Best road to go, would maybe be to Ask the GTK guys to push back GTK4 and do a collaboration so that after GTK4 is out, its possible to slowly port KDE to GTK4 without to much missing features on the framework side.
What do you think?

Push back GTK+4 as in to delay its release? You mean to integrate more features, which might be needed for a port of KDE?

[Volta]

Best road to go, would maybe be to Ask the GTK guys to push back GTK4 and do a collaboration so that after GTK4 is out, its possible to slowly port KDE to GTK4 without to much missing features on the framework side.
What do you think?

Would be awesome. And what's the best about this idea it's no longer 'trolling', but something worth to think about.

[TemplarGR]

This sounds really bad. Most Bugs I report are Qt bugs. So now they will stay much longer in until they come down the line for KDE. In case of LTS distros this could end in 5years of waiting for simple bugfix.

On the other end, if KDE would fork, at some point it would just not be compatible with Qt-company-Qt anymore so no crossporting and that means bitrot with a smaller community.

Best road to go, would maybe be to Ask the GTK guys to push back GTK4 and do a collaboration so that after GTK4 is out, its possible to slowly port KDE to GTK4 without to much missing features on the framework side.
What do you think?

This will be harder than you think. It will take a lot of time. I think that option would be left as a last resort.

If shit hits the fan, they could go the Cinnamon route, re-create KDE on top of GNOME/GTK 4 (i suppose by that time it will be out). It will be faster. They can create the GUI as they see fit, they can adapt whatever is salvageable from frameworks and KDE Applications, and for larger apps that are harder to move to GTK4 or they don't want it, they could keep using Qt individually, it is not like Qt apps are not usuable under GNOME

[DeepDayze]

Would be awesome. And what's the bes+1t about this idea it's no longer 'trolling', but something worth to think about.

+1

Wonder how much better KDE would be if run on a GTK+4 base and how difficult would be to port the existing KDE frameworks to GTK4? I can picture a skunkworks project that would port KDE to GTK framework.