I am not a KDE dev, but interested in that topic.
To partiticipate you can sign up in the forum, and maybe stay a bit and help other users ;)
I am not a KDE dev, but interested in that topic.
To partiticipate you can sign up in the forum, and maybe stay a bit and help other users ;)
Yes I agree. There is a switch you can use to block installing Addons.
But that is also not nice. Sandboxing them, having a manual review process, would help. But that is a TON of work.
I also change some things like UI buttons and find it to be a core requirement. At the same time, I could live without extreme theming, or just having widgets on the panel, or just having a bottom panel etc.
This is a difficult decision, so I thought it would be a good idea to just find out what some users want.
This is why it would make sense to have a restrictive and simple API that supports basic extensions with little oversight. Configuration only; no executable code.
For the small minority of add-ons that would require executable code, there could be a separate API with a more involved installation process, making it obvious to the user that the trust and risk levels are different from the above. A sandbox feature could perhaps be developed in the long run, but that is indeed a ton of work and hard to get right, and isn’t really necessary for this approach to be effective. Just having a software-style installation process (e.g. through a distro’s package manager) and different APIs would go a long way toward protecting users.
And KDE components could be migrated to use that API and be separatable.
Currently it may be a bit messy.