Maybe create GDE (Good DE) 1:1 features copy of KDE but based on gtk
Announcement
Collapse
No announcement yet.
Qt 5.15.3 LTS Released With 200+ Bug Fixes, But Only For Commercial Customers
Collapse
X
-
Originally posted by acobar View Post
tildearrow,
Click on settings of Krunner and disable what you don't need it to search for. Problem solved. I bet you also disabled the kde indexing, besides also using a slow (but trustworthy) HD.
Best regards.
Yes, I disabled Baloo for being slow. Couldn't they have used locate-like technology instead, or at least run the search in another thread?
Comment
-
What a load of garbage comments, full of hate and misinformation. Good thing KDE developers are not here reading all this crap and are doing productive things.
First, Qt is still GPL
Second, all the changes in the LTS that will now be commercial only, will be available in Qt6 under GPL license in the future.
KDE does not need to make any fork of Qt at the moment.
All GPL software made with Qt will remain GPL now and in the future, oh surprise!
Stop talking nonsense.
- Likes 8
Comment
-
Originally posted by yossarianuk View Post
Well if you want the best KDE experience you will be running the latest version, so you won't be using LTS QT anyway.
And if I see what kind of modules missing I can only say -> sorry no .. that missing nearly everything I need!
- Likes 2
Comment
-
In my opinion, the only reason this is an issue at the moment is because 5.15 is the last release of Qt5. So you have four options:
* Stick with 5.12.x until 2021.12.05 (IIRC 5.12 is not affected by this change)
* Stay on 5.15.2 and deal with any toolkit bugs
* Stay on 5.15.2 and backport/apply patches as seen fit from the 6.x branch (possibility of distro maintainers doing such a thing with the Qt "upstream first" policy in place, but knowing what specifically to backport will be the challenge)
* Go straight to Qt6, which requires varying amounts of porting work and doesn't have a complete ecosystem yet
I assume most people developing distro/FOSS applications with Qt will be using their distro provided libraries, rather than the precompiled binaries provided by Qt Company or self-built ones. Those are usually utilized by those building applications where they bundle the library along with the application for delivery, which isn't usually the way distro packaging/development works (or if they want to build a CI system with a minimum version requirement). And distros find themselves on a range of Qt5 versions (listing unsupported releases to show progression, obviously some of these contain significant backports [can't find manifests for non-LTS Ubuntu versions pre-20.10]):
Fedora 30: 5.12
Fedora 31: 5.13
Fedora 32: 5.14
Fedora 33: 5.15
RHEL 7: 5.6, then 5.9
RHEL 8: 5.11, then 5.12
Debian 8: 5.3
Debian 9: 5.7
Debian 10: 5.11
Debian testing/unstable: 5.15
Ubuntu 16.04: 5.5
Ubuntu 18.04: 5.9
Ubuntu 20.04: 5.12
Ubuntu 20.10: 5.14
Ubuntu 21.04: 5.15
OpenSUSE Tumbleweed: 5.15.2
OpenSUSE Leap 15.0: 5.9
OpenSUSE Leap 15.1: 5.9
OpenSUSE Leap 15.2: 5.12
OpenSUSE Leap 15.3: 5.12
Obviously the ideal scenario would have been that this isn't happening, with the next best situation having it start with Qt6, rather than the Qt5 series. As much as it sucks, I don't think it's unreasonable for a company to say that if you want long term support, you need to pay for it, particularly considering those patches have already been upstreamed. However, requiring applications to port to a newer major version of the toolkit (even with the statements that it won't be too much of a change) is a non-trivially dick move and something I view as a way of forcing these applications to migrate if they require a critical fix only available in that new patch release. After that though, it doesn't seem like such a massive deal* once the ecosystem reaches critical mass on the newer version, and distros ship both series in tandem.
Hiding the release notes behind a paywall though, that, I do not like.
Cheers,
Mike
* Until Qt7 where rinse and repeat, but that is a good solid several years out (Qt4 -> Qt5 ~> 7 years, Qt5 -> Qt6 8 years).
- Likes 2
Comment
-
Originally posted by mroche View PostIn my opinion, the only reason this is an issue at the moment is because 5.15 is the last release of Qt5. [...]
- Qt didn't have a LTS release until 2011 (4.8), and that was OK.
- GTK didn't have a LTS release, and that was OK [if it has any nowadays, because there is no mention of any GTK LTS (nor any similar term) in the GTK main page (https://www.gtk.org/) nor in the downloads pages (like https://www.gtk.org/docs/installations/linux/), etc. It makes you wonder if it exists.]
- Distros backport manually almost all fixes themselves for all projects since forever.
- LTS releases are for business that ship their own Qt copy [and that comes handy to pay developers].
- Likes 5
Comment
-
Originally posted by Nth_man View Post
...
My current industry has some thinking to do with the VFX Platform and how the Qt5 -> Qt6 and future changes will be handled; we usually stick to LTS, but some companies do ship LGPL libs instead of the proprietary licensed ones.
Examples:
http://help.autodesk.com/view/MAYAUL...omponents_html
Cheers,
Mike
Comment
-
Originally posted by Alexmitter View Post
Thats what they did say in the first 4 years of KDE where Qt was not available as GPL at all and was fully proprietary, that's also what they say for the other 21 years since then continuously happily accepting every weakening of the contract between the Qt Company and KDE e.v. that now made it turn into nothing but toilet paper.
KDE people are always and were always happy to work with the worst of the industry.
- Likes 1
Comment
Comment