I have had major issues ever since updating to plasma 6.3, likely due to a theme I was using (Klassy) not being updated for 6.3 yet. I believe a system should absolutely be in place to prevent regular updates from resulting in a mismatch between themes and desktop versions – especially if those updates cause breaking changes.
Where would it make the most sense for changes like this to be implemented? Distros, Desktops, the themes themselves, or somewhere else?
Distro would make sense, because I can imagine an issue like this being no issue for an Arch user, but as a Fedora user I need to reinstall because I haven’t ever had to deal with anything like the issues this has caused.
Desktop would make sense, because the themes are desktop-specific.
I don’t know what level of control the developers of themes even have for implementing something like this.
Themes in the sense I’m talking about (such as Klassy) are desktop-specific, so I believe a system for this could be implemented to Discover.
For example, a panel on the update screen in discover:
A new major version of Plasma Desktop is available;
however, there are installed themes that have not been
verified to work with it and may cause problems.
Update at your own risk. [update checkbox, toggled off by default]
Any thoughts from those with a lot of experience? If themes are going to be supported as much as they are, I think a completely regular update causing such problems (the update screen did not say anything about updating to 6.3), especially on stable distros like Fedora, needs to be addressed.
Hi - I don’t use Klassy, or anything like it, but for what it’s worth…what you’re talking about sounds like part of dependency management. That could be handled if it - or any similar software - were packaged as part of a distribution’s managed repositories.
How did you originally install Klassy, and how do you update it?
I admit that Klassy may be an outlier even if my exact idea was implemented due to how many features it has, it needs to be installed through cloning the github repository or an rpm. I assume that dnf handles its updates because it doesn’t seem to come with any updating tool and is a slight pain to remove fully.
Thinking further, the issue might be minor with regular themes and I should instead be posting about giving “normal” themes the ability to do what Klassy does–primarily, highlights around the selected window (like Cosmic).
Yeah, based on your experience it sounds a bit like it’s functionally “system software” - involved installation, painful removal, big impact to the running system - and those can definitely be tricky if they’re not part of the distribution’s main repositories, since they can’t really be kept in coordination by the distribution’s maintainers along with the rest of the operating system.
I’m probably thinking in too limited of a way, but it seems like a type of problem that package management tools were made to solve? For example, if a Klassy package had in its spec file that it conflicts with KDecoration >= 6.3, then attempts to upgrade a system with that in place would surface the conflict, and the user could then either reject the upgrade or uninstall the blocking package.
In the future of image-based OSes - I think you’re right-on that the ultimate solution would be figuring out how to accomplish the effects that you want, without having to layer additional software onto the base system
