SUMMARY They are some folder icon without symbolic in their names which allays appear symbolic even if symbolic versions of them exists. If icons are enormous we still get enormous simple symbols. It is not normal to get exactly the same behavior than if we were using symbolic icons. This is the case for every folder icons related to mails and some others like server-database or document-multiple. Those are cases where there are symbolic and "not symbolic" version (with "not symbolic" being exactly like symbolic) but I have found one case of folder which does not have a not symbolic version and should have one : folder-saved-search-symbolic (there is no "folder-saved-search"). STEPS TO REPRODUCE 1. Open a folder with multiple sub-folders 2. Put an affected folder-icon on one of the folder (right-clic > properties > clic on icon) 3. Switch to the third view (the detailed list view) and zoom in and out to see other folder changing between folder and symbolic 4. See that the affected icon does not switch as they should. OBSERVED RESULT Some icon does not get the style they should and stay symbolic even with enormous zoom level (see attachment). EXPECTED RESULT Every icon with not symbolic in their names should switch to a folder or with detailed looks on large sizes (for coherency, beauty and better distinction). SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-28-generic (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION There is a bug which is the inverse of this one : icons with no symbolic versions (bug 486316).
Created attachment 169019 [details] Video showing "not symbolic" folder icon with symbolic appearance
Created attachment 169020 [details] Folder of folder icons with symbolic looks even without being the symbolic version The folder used for the video example. For folder icons always showing symbolic looks instead of detailed looks. The folder needs to be unzipped for icons to show.
Created attachment 169043 [details] Illustration of the issue in folder-icon choice An annotated screenshot illustrating the issue from the view of icon selection.
This is basically intended; not every icon needs to have both symbolic and full-color versions in the Breeze icon design language. In particular, actions icons are almost always only symbolic, and the icons you're showing here are action icons. Action icons are not intended to be shown at enormous size; it's best to pick a different an app, category, preferences, or device icon instead.
(In reply to Nate Graham from comment #4) > This is basically intended; not every icon needs to have both symbolic and > full-color versions in the Breeze icon design language. In particular, > actions icons are almost always only symbolic, and the icons you're showing > here are action icons. Action icons are not intended to be shown at enormous > size; it's best to pick a different an app, category, preferences, or device > icon instead. So why is it not in the "actions" category ? - Why is there a "user-identity" in the folders category when "user" and a lot of things related to user are in the "actions" category ... and even an other "user-identity" ! ? - I don't know why "folder-add" is not in the "actions" category. "folder-new" is in "actions". It's clearly not normal. - "actions" category already has things like "bookmarks" (a category of stored things) and stuff related to mail, so why are mail categories with folders ? If is it to use it on folders then it should have folders icon for the version without symbolic in the name. If it should not be used on folders then it should probably be in "actions". - contrary to "bookmarks", "favorites" is with folders, so we could ask why not "bookmarks" with folders or why not "favorites" in actions ? I would say that the word "favorites" is something that feel a bit more general that "bookmarks" and that we could use it for everything, so putting it on folders for multiple reason. But for that we have "folder-favorites" and I use it myself on multiple folders. "favorite" is in "actions" (as it should), "folder-favorites" is with folders (as it should) and "favorites" is with folders (which is subject to debate because it can be seen as exactly like "folder-favorites" so useless duplicate or as an action to go to where are favorites so would be more an action). - For folders we have "folder-database" (a folder with database icon) which is useful. So I don't care we don't have a folder version for "server-database", "repository" and "network-server-database". - "folder-saved-search-symbolic" has no version without symbolic in the name. And there is no other folder icon that allow to use a magnifying glass icon, so it could be useful to have one (folder with magnifying glass) to point out that a folder contain search related stuff. - I know what xcfe is but not what "org.xfce.gigolo" is supposed to be. - I don't know what use-case "document-multiple" has.
To be less confusing, maybe we should have : every icon with names like "folder-things" should be an icon for folders to store that thing (with folder icons), name "view-things" for action icon to go to those things, name "thing-true" for an icon on something to say that it is part of the thing (in action category) (when we click on it, it could become "thing-false"), name "add-thing" or thing-add" for the action icon to add the thing category to something, name "thing-new" for action icon to create a new thing object, no "things" because it could be confuse with "folder-things" and "view-things". Those things are already mostly true in most cases. Except "true", "false" that I have never seen used. For singular name that implies containing multiple stuff like "database" it can create many confusion if the name is not precised (folder (to put on folder), view (action), add, true). Symbolic being always symbolic is always true.
Sorry for being annoying, it's little things, I want to see KDE becoming perfect.
The dirty secret is that the category-based organization has no effect on anything, so there's no real reward for cleaning it up. There's also no reason not to--other than no one having time for it since we're all overloaded with work. If you'd like to take the lead here to clean up some of these mis-categorizations, that would be a great way to get involved and learn about icons.
(In reply to Nate Graham from comment #8) > If you'd like to take the lead here to clean up some of these > mis-categorizations, that would be a great way to get involved and learn > about icons. Ok. I will probably not found the time to get into the KDE development ecosystem to do that (as I also have some more important things that I should found the time (days) to do).