KDE Now Maintaining Their Own Set of Patches For Qt 5

[discordian]

So there are already halfway towards doing their own https://www.copperspice.com/, why not just move over?

[Alexmitter]

As I said in several discussions .... this was to be expected. Once you have switched to Qt6 there will be no more problem. This problem exists only in the transition period to a higher version.
I don't think this is a big deal, it's just about patching any security issues or bug fixes.
Usually the latest version of a cliclo (4,5,6 etc.) is always in good condition, so there won't be much to do.

It will take the KDE Community about 5 years from now to port the at least still frequently used projects.

[bug77]

To all those fretting "omg, fork!", KDE already routinely contributes patches to Qt. It's just that for this particular branch (5.15 LTS), contributions won't make it back to a public release, so KDE has to maintain the patches themselves for a while.
Like I've said before, I don't have a problem with the new Qt policy, but around 5.15 is probably the worst time to implement it. This being one of the side effects.

[lumks]

I don't have a problem with the new Qt policy, but

Don't use "but" if you have trust in your words. But is always the end of a lie, followed by the truth.
Back to the topic

around 5.15 is probably the worst time to implement it. This being one of the side effects.

I actually do think this is intentional. That way people don't have anything to switch to. There is no next-compatible release and everything that was before is in a worse state. KDE might be Qts collateral damage in this "Framework war", so I actually think KDE should act in some way. Not with a fork, because that would be just an "keeping alive an outdated Qt version". It would be possible to extend framework 5/6 into an growing base-framework and grow this one over time into some KDE own framework. So there wouldn't be a hard cut, instead it would be a slow move-away to something own.

Or, you know. join GTK to create a GTK(mm)5 that also works for KDE to switch to, BUT that might be me trolling.

[lumks]

I'm sad about this whole situation. KDE is kind of a small team. A team of people who show of whats possible with Qt and doing so for years and years. Yet they have to do even more work because of this situation. From the users point of view - is there anything we can actually do?


https://relate.kde.org

http://www.kde.com/donations

[ssokolow]

Or, you know. join GTK to create a GTK(mm)5 that also works for KDE to switch to, BUT that might be me trolling.

As someone who's coded against both (albeit in Python), I have to say that GTK is so feature-poor compared to Qt that doing that just isn't viable in any near-term case.

I switched to Qt before GNOME 3.x-isms started to pollute the LXDE components I was mixing into my KDE and you'd have to pay me to go back to reinventing those wheels. Now, I imagine KDE would have to maintain something like the gtk3-classic patch set on top of that because of all the unwanted GNOME-isms that are getting forced onto non-GNOME desktops built on GTK.

[Alexmitter]

Alexmitter Read the FAQ. They are going to backport from CLAed Qt6. KDE also announced they are moving to Q6. No forks are planned.

I am aware of that, and I am aware that this is what they would like to do. But it wont work, at least not for everything. They will have to fix issues themself that do not exist in Qt6 anymore due to completely different code base that they can not simply pull into their qt5.

[Alexmitter]

I switched to Qt before GNOME 3.x-isms started to pollute the LXDE components I was mixing into my KDE and you'd have to pay me to go back to reinventing those wheels. Now, I imagine KDE would have to maintain something like the gtk3-classic patch set on top of that because of all the unwanted GNOME-isms that are getting forced onto non-GNOME desktops built on GTK.

Looks like someone is afraid of everything that does not look and work like windows 95. Real spooky.

In fact KDE maintains a breeze theme for GTK3 and it looks quite nice, better then their own breeze qt theme I would say. But that is mostly due to GTKs extremely flexible css based theming.

[Nth_man]

As someone who's coded against both (albeit in Python), I have to say that GTK is so feature-poor compared to Qt that doing that just isn't viable in any near-term case.

That's right.

[bug77]

Looks like someone is afraid of everything that does not look and work like windows 95. Real spooky.

In fact KDE maintains a breeze theme for GTK3 and it looks quite nice, better then their own breeze qt theme I would say. But that is mostly due to GTKs extremely flexible css based theming.

This isn't about looks, it's about (missing) functionality/configurability.