Hola,

For the longest time I was annoyed by dolphin having a fishy icon in discover, which as it turns out is because it uses a default icon name so it gets a silly icon from a silly theme as appstream has no proper way of handling this.

BUT

That lead me to notice that there is branding identity problem with how most of our apps handle icons. Our applications for the most part assume the default icon theme as their icon, so discover's icon is the current breeze icon, kmail's icon is the current breeze icon and so on and so forth. The problem is that during oxygen times we did that explicitly (application icons were to a large part maintained in the application repositories) form which we moved away with breeze (application icons are only maintained in the theme repository).

This leads to two problems:

1) Applications that are old enough to have been around in oxygen times now install a oxygen-style hicolor icon (e.g. kmail here [1], kwalletmanager [2]) and I suspect most authors are even unaware of this.

2) Unless we move maintenance out-of-theme (which is not going to happen FWIW) there is no straight forward way I can find to get the apps to use their intended default icon as per breeze without having everyone copy the icon from breeze and then not get updates in case we update the icon in the theme.

Thought everyone should know, and maybe someone can find solutions :/

2 probably ought to be dealt with before 1, at which point we probably can use build.kde.org to do automated detection of icon origins by doing pixmap comparision? Dealing with the second problem is the somewhat greater and more annoying problem. A possibly approach I could think of is make breeze-icons an actual build-time dependency and have an ECM macro that picks an icon from breeze an installs it into hicolor. I am not sure that is all too lovely though.

[1] https://github.com/KDE/kdepim/blob/master/kmail/src/icons/64-apps-kmail.png [2]
https://github.com/KDE/kwalletmanager/blob/master/src/manager/64-apps-kwalletmanager.png

HS