Bug 438582

Thanks, and yes, that's confirmed.

Now, of course, the super annoying part of my response: This is a non-trivial issue. Basically, we've no good way to determine whether things should be removed again automatically. It's akin to what happens with package managers, where there's no good way to detect whether something is still desired by the user. We /can/ detect whether something is still required by another specific thing on the system (that is, knewstuff can't, but kpackage (the bit that does the cross-origin bits) can do this, or at least be taught how to), and we can detect whether something is in use and refuse to remove it, but what we can't detect is whether the user wants to get rid of the main thing, but still wants to use something.

That final bit, though, is arguably something where we just have to ask the user whether that's what they want to do, probably with the things that we know are safe to remove pre-checked, and the others not selected, with a description of why they're not selected (required by something else), or not available for removal (because they're in active use).

But, yeah, in short, not a trivial issue, but one that we do want to try and work out how to deal with properly.

(In reply to Dan Leinir Turthra Jensen from comment #1)
> Thanks, and yes, that's confirmed.
> 
> Now, of course, the super annoying part of my response: This is a
> non-trivial issue. Basically, we've no good way to determine whether things
> should be removed again automatically. It's akin to what happens with
> package managers, where there's no good way to detect whether something is
> still desired by the user. We /can/ detect whether something is still
> required by another specific thing on the system (that is, knewstuff can't,
> but kpackage (the bit that does the cross-origin bits) can do this, or at
> least be taught how to), and we can detect whether something is in use and
> refuse to remove it, but what we can't detect is whether the user wants to
> get rid of the main thing, but still wants to use something.
> 
> That final bit, though, is arguably something where we just have to ask the
> user whether that's what they want to do, probably with the things that we
> know are safe to remove pre-checked, and the others not selected, with a
> description of why they're not selected (required by something else), or not
> available for removal (because they're in active use).
> 
> But, yeah, in short, not a trivial issue, but one that we do want to try and
> work out how to deal with properly.

The problem is that the removed item is called "global theme" which means user already knows it has many sub components installed (icons, cursors, colors...), and if user wants to remove only a sub component of it like icons or cursors it can be done by going to the specific page (Cursors, Icons, Colors...) in Plasma Settings. So from my point of view removing a global theme should automatically erases all of its sub components (even its SDDM theme by prompting for root password like it's done when installing).

It's like we need some kind of reference-counting system...

I've also faced this issue on plasma 5.24.5 (Manjaro Linux). I have tried to uninstall the global theme through discover where it removes itself from the install list. But the theme and all of it's components are still visible through the various appearance setting pages. I've also seen this happen on several machines with Manjaro installed. Is there any workaround I can try and any other details I could provide? 
thanks

#installing  global themes can install items into these settings pages, but may not remove them all
- Appearance > Global Theme
- Appearance > Plasma Style
- Appearance > Colors
- Appearance > Windows Decorations
- Appearance > Icons
- Appearance > Cursors
- Appearance > Splash Screen
- Startup and Shutdown > SDDM
#may need to manually go to each settings page and click on the red trash can, then hit apply