SUMMARY The Breeze “Places” icon “folder-podcast” is missing 3 variants, specifically: 48, 96, symbolic STEPS TO REPRODUCE 1. See https://invent.kde.org/frameworks/breeze-icons/-/tree/master/icons/places/... folders for missing 'folder-podcast' (and 'folder-podcast-symbolic') icons. OBSERVED RESULT Missing icons. ADDITIONAL INFORMATION All other variants are present, but the symbolic icon (most important variant, given the ability to use others) is critically missing.
It looks like the 48, 96, and symbolic directories are missing a lot of places icons, in fact. Odin, can you comment on the real-world impact that this is having for you?
(In reply to Nate Graham from comment #1) > It looks like the 48, 96, and symbolic directories are missing a lot of > places icons, in fact. Odin, can you comment on the real-world impact that > this is having for you? Ah, certainly, Dolphin and Gtk software that use 'Places' just like Dolphin does can't show any correctly symbolic icon for podcasts if a folder has been set to a 'Places' similar to how ~/Documents and ~/...folders are typically used.
I'm curious why icon-related stuff like aren't automated from vector/SVG originals, is it because it is low priority?
Thanks for the info. It's not possible to automate this in a way that preserves the pixel-perfect nature of each size. And if we don't actually care about that, then we can just use a single base size since SVGs are scalable. But they aren't scalable in a pixel-perfect way. :)
(In reply to Nate Graham from comment #4) > Thanks for the info. > > It's not possible to automate this in a way that preserves the pixel-perfect > nature of each size. And if we don't actually care about that, then we can > just use a single base size since SVGs are scalable. But they aren't > scalable in a pixel-perfect way. :) I think it'd be better to have something than nothing. Maybe an SVG base that is automatically converted to each variant and marked for preliminary approval/verification before adjustment.
Update: added all the missing icons @ 96px in https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/273. By the way, it seems like none of the symbolic/16px are missing, including `folder-podcast`.
(In reply to Manuel de la Fuente from comment #6) > Update: added all the missing icons @ 96px in > https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/273. > By the way, it seems like none of the symbolic/16px are missing, including > `folder-podcast`. They are missing. https://invent.kde.org/frameworks/breeze-icons/-/tree/master/icons/places/48 https://invent.kde.org/frameworks/breeze-icons/-/tree/master/icons/places/96 https://invent.kde.org/frameworks/breeze-icons/-/tree/master/icons/places/symbolic
I've also noted that the 16 non-symbolic has an RSS icon instead of podcast, plus the icon has an artifact, top-left of that circle is distorted.
(In reply to Odin Vex from comment #8) > I've also noted that the 16 non-symbolic has an RSS icon instead of podcast, > plus the icon has an artifact, top-left of that circle is distorted. The folder is also colored, for some reason. It's the wrong icon for a podcast folder and it shouldn't be colored (blue default).
> They are missing. Yeah, I linked to the (then unmerged) merge request. Now that it's merged, it's there. I probably should've sent the other comment after merging. Also, as far as I'm aware, the symbolic folder just acts as a folder of icon symlinks from non standard GNOME icons to the freedesktop ones, so adding the 16px icon there makes no sense unless it's a GTK based podcast app that's missing the icon, which if it is, would have a different name. > I've also noted that the 16 non-symbolic has an RSS icon instead of podcast All the `folder-podcast` icons use the RSS icon > plus the icon has an artifact, top-left of that circle is distorted. The 16px non-symbolic variant looks pretty normal here. Adding it to the Dolphin `places` pane on the sidebar renders it fine > The folder is also colored, for some reason > It's the wrong icon for a podcast folder and it shouldn't be colored (blue default). I think that's a different issue. Here's my thoughts on this: Some of the newer `folder-${TYPE}` icons have color, which for the non `folder-${COLOR}` icons is, in my honest opinion, not a good idea, since it's inconsistent with the rest for no real reason. Why would an user want the RPM folder to be red, but the Snap and Flatpak folder to be blue? I also agree that the RSS icon isn't the right metaphor, as that is just one of the channels where the user might've gotten the podcasts from, and doesn't represent the concept of an actual podcast. But still, this issue is about the missing size variants, so I stuck to adding the missing variants for now. I can do a MR to turn those folders monochrome/blue like the rest, and another for changing the RSS logo to something like a microphone or another more fitting icon, but after I'm done with the other ~35 icons for the 48px size. It's more important to have no missing icons first.