https://bugs.kde.org/show_bug.cgi?id=417776

--- Comment #4 from Nate Graham <n...@kde.org> ---
(In reply to Sadi from comment #2)
> I fully understand that widget icons should always be monochrome/symbolic in
> the panel irrespective of panel thickness.
> 
> I think maybe a better solution could be achieved - if possible - if this
> can be made conditional - i.e. if it is a dock and not a panel, then a
> colorful icon from the current icon theme should be used instead like the
> app launchers in that dock (for instance, as I use Latte Dock in Unity
> layout, I can see that I have a top "panel" and a left "dock"; and some
> users may have a Mac-style bottom dock as well).
Unfortunately there is no way for a Panel to know if it's being used as a dock,
a taskbar, a global menubar, a pull-out widget drawer, or whatever. It is just
a generic container for holding widgets. In the past, we roughly approximated
what you wanted by having things change their visual style according to
thickness, on the logic that taskbars and global menubars would be on thin
panels and their users would want everything monochrome, and docks would be on
thick panels and their users would prefer colorful icons. But in practice it
didn't seem to work out and we kept getting bug reports about the icons
changing style based on panel thickness and now people thought it was weird.

I actually agree with you that with a thick macOS/Unity style dock, it is nicer
to have colorful large widget icons. However this is also kind of inconsistent
since the system tray icons will always be monochrome. We wrestled with this
conundrum and in the end settled on the current imperfect solution of just
always using monochrome icons no matter the thickness.

(In reply to Sadi from comment #3)
> I'd like to add that editing "user.svgz" and removing the larger (64px and
> 48px) user-desktop icons from it *almost* achieved the desired result. But I
> saw consistently blank space until I hovered on it to display the standard
> color user-desktop icon, which I could overcome only by removing the file
> "user.svgz" altogether. That's fine for me as a workaround, but I think
> perfect solution would be as I've suggested above.
You may need to delete ~/.cache/plasma* afterwards.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to