| Summary: | Breeze replaces SMPlayer icon | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | Nikos Chantziaras <realnc> |
| Component: | Icons | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | CLOSED NOT A BUG | ||
| Severity: | task | CC: | bugzilla, kde, mtmkls, uri_herrera |
| Priority: | NOR | ||
| Version: | 5.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Upstream smplayer icon | ||
|
Description
Nikos Chantziaras
2015-08-27 08:15:55 UTC
This is not a bug. (In reply to Uri herrera from comment #1) > This is not a bug. I'm sorry, but how is this not a bug? The application is prevented from using its icon. I am unable to see the application's icon/ It is a bug. Just because someone put an icon there on purpose doesn't mean that this isn't a bug. It's not a bug, the icon is not missing. This is not different than other appliction icons replaced by a Breeze icon like Inkscape, VLC, Steam, etc. (In reply to Uri herrera from comment #3) > It's not a bug, the icon is not missing. This is not different than other > appliction icons replaced by a Breeze icon like Inkscape, VLC, Steam, etc. And this should NOT happen. KDE has no right to replace my icons. This means that this is a bug for the other instances too. KDE replaces perfectly fine icons without any reason whatsoever. Please, can you explain to me why this is not a bug? Note: "it's done on purpose" is not a reason. Just because you introduce a bug on purpose, does not mean it's not a bug. Created attachment 94492 [details]
Upstream smplayer icon
Here's the upstream icon from smplayer. It's perfectly fine. No problems. Looks nice. Someone explain to me why this has to be replaced by KDE with some ugly looking icon, and resulting in confusion about smplayer's icon missing.
It seems I get no replies without changing the status... I'll say it again: this is not a bug as the icon is not missing. We provide icons for some applications in order for these to have certain level of integration with Breeze, if at least have their application icon match Breeze's style. This a list of the applications we provide a Breeze icon for: Clementine Bleachbit Blender Bomi Cantata Chromium Filezilla Gimp GRUB Customizer GTKHash Htop Inkscape LibreOffice suite NTFS Config Octave Octopi Oketta QBittorrent QtCreator QElectroTech Showfoto Smartgit *_SMPlayer_* Sublime Text Telegram Unetbootin XChat VLC Vokoscreen Along with: AMD Catalyst Google Chrome Google Play Music Copy Dropbox Firefox Spotify Steam Youtube* Like I said in the comments above, the SMPlayer icon is replaced by a Breeze version, like all the other applications in this list have their own replaced once installed. With that said this is not a bug. Yes, it is a bug, because the application's own icon isn't working anymore. It is replaced by Breeze. It didn't ask me if I want to replace the icon, and it's not optional. It just replaces it without my consent. Again, the bug is: The SMPlayer icon, as shipped by SMPlayer, is NOT shown. It does NOT work. I can NOT see it. I don't know how else I can explain it to you... (In reply to Uri Herrera from comment #7) > Like I said in the comments above, the SMPlayer icon is replaced by a Breeze > version, like all the other applications in this list have their own > replaced once installed. > > With that said this is not a bug. There will be users who do not want native application icons replaced. Providing Breeze alternatives is fine ... just don't enforce it, that may well be seen as arrogance on the part of the Breeze designers ;) ... user choice is Very important you know. Hi Nikos Chantziaras and Paul, Breeze is an Icon Theme as any other icon theme too. e.g. if you look at faenza icon theme the design guidelines are boxes and therefore all application icons are different from the "original" application icon so that the design will follow an guideline. http://img12.deviantart.net/82d7/i/2012/302/8/f/faience_icon_theme_by_tiheum-d47vo5d.png Breeze also have guidelines and therefore we offer the user an consistent look and feel through as much applications as possible. And therefore also the application icons should follow the same guidelines. If you don't like the smplayer icon, no worry than please delete the application icon in /usr/share/icons/breeze/apps/... than you will get the original smplayer icon from the application source. If there is a trademark issue with the smplayer icon we will remove it. if it is only cause you don't like it, please submit an better icon. I understand that someone don't like it, but we also have to think about an consistent look and feel and therefore the icons have to follow our guidelines. So we not only say, this is cooler and we make it because I'm the hero, we have guidelines and we are working according to our guidelines. https://techbase.kde.org/Projects/Usability/HIG/IconDesign What you're basically saying, is that you're trying to enforce Breeze guidelines to projects unrelated to Breeze or KDE... The Breeze guidelines should apply to Breeze icons. Not to icons of third-party applications. Replacing those should be *optional*, not *mandatory*. Additionally, the icon of an application is part of its identity. Changing it is just as bad as changing its name. For the same reason you should not replace "Firefox" with "Waterlion", you should not replace its icon with something else. At least not without users having a say in this. If you want to make this more sane, please provide the override icons in a different package, or at least a different directory, so that I can just "rm -r" it without also deleting KDE-specific icon overrides (KMix, etc.) Please be more considerate and don't remove well-known icons that are part of an application's perceived identity. (In reply to Nikos Chantziaras from comment #11) > What you're basically saying, is that you're trying to enforce Breeze > guidelines to projects unrelated to Breeze or KDE... > > The Breeze guidelines should apply to Breeze icons. Not to icons of > third-party applications. Replacing those should be *optional*, not > *mandatory*. That's not what I saw. The icon designer have to look after an consistent design not like you know it from windows where each application have an different style. And I made an Breeze Icon set for SMPlayer too and submit the package to the SMPlayer dev and he pushed it to the next release so that the kde breeze user have the breeze icons in SMPlayer too. But what't the problem of delete the application folder? e.g. KMix and any other application ship an application icon so you get the KMix icon that the developer defined. Same for Amarok, VLC, .... remove the folder from the breeze icon set and you get what you want. the look and feel from the devs. (In reply to andreas_k from comment #14) > .... remove the folder from the breeze icon set and you get what you want. > the look and feel from the devs. Not a particularly elegant solution though, is it? I know you guys are after a consistent 'look' but... Comment 12 is well worth reading again. We try and make 3rd party apps fit in with Breeze. That's the goal. If you prefer another icon set that doesn't do this, use a different icon set. (In reply to David Edmundson from comment #16) > We try and make 3rd party apps fit in with Breeze. That's the goal. > > If you prefer another icon set that doesn't do this, use a different icon > set. I like how you ignored every single argument. Good job. it is easy. we have guidelines and when one user say ignore our guidelines the answer must be no. @Nikos Chantziaras: The purpose of an icon theme (Breeze, Oxygen, whatsoever) *is* to replace native icons! The more complete an icon theme is, the more native icons get replaced. So Breeze icon theme does its job, no bug. If you don't want an icon theme to replace your beloved application icons you have to create an own theme and use it. This can be a very easy theme just containing the few icons you don't want to be replaces and then use the inherit option in the theme file of your personal theme to include all other icons from Breeze (or any other theme you use). This is the usual strategy/procedure since KDE uses icon themes. The other strategy is to replace that very special icon in the theme with your beloved icon but that can be overwritten with any update. If you don't want *any* icon to be replaced use the included hicolor theme. > The purpose of an icon theme (Breeze, Oxygen, whatsoever) *is* to replace native icons!
Yeah, for KDE apps maybe. Not for third-party apps!
And Breeze is the visual style for the Desktop (window decorations, widgets, etc) which I want. But it also replaces third-party app icons, which I don't want, and which is not OK.
(In reply to Nikos Chantziaras from comment #20) > > The purpose of an icon theme (Breeze, Oxygen, whatsoever) *is* to replace native icons! > > Yeah, for KDE apps maybe. Not for third-party apps! For *all* apps, not only KDE apps. That's a standard - since years - for all linux desktop environments, not only Plasma 5. > And Breeze is the visual style for the Desktop (window decorations, widgets, > etc) which I want. But it also replaces third-party app icons, which I don't > want, and which is not OK. The style and window decorations have nothing to do with the icon theme. But as I already wrote, create your own icon theme which inherits breeze, then you get what you want. Or just create a breeze theme folder in your home ~/.local/share/icons/ and copy the relevant third party icons into it (into the correct subfolders), breeze then will respect them. I'm talking to walls here, so let's just drop this. You have different options to work around the problem. This does not affect just Breeze or Plasma 5 but all Linux GUIs and icon themes which follow the guidelines. But maybe you/someone can alter this into a wishlist entry for adding an option to Plasma's icon configuration to *optionally* respect application icons in /usr/share/pixmaps. Dear Uri, Andreas, Dave, and every other contributor of Breeze, you should never ever ever ever ever ever replace the well-known icons of 3rd party applications with some totally different stuff you invented. Never! Never! Never! Never! If your guidelines say otherwise, your guidelines are crap. By the way I took a look at the KDE HIG, and this is what I found in https://techbase.kde.org/Projects/Usability/HIG/IconDesign : " When creating an system icon theme, respect trademarks by avoiding significant alterations to application icons. " This basically says you shouldn't replace the icon of VLC with https://github.com/NitruxSA/breeze-icon-theme/blob/master/Breeze/apps/48/vlc.svg that doesn't feature an orange cone, and you shouldn't replace the icon of VirtualBox with https://github.com/NitruxSA/breeze-icon-theme/blob/master/Breeze/apps/48/virtualbox.svg that I don't even know what it wants to symbolize. Ergo, this bug is not invalid, and must be fixed ASAP. Very well then, I will remove every single icon that is not a KDE software icon. But I won't take any complaints whatsoever that (these app) icons are missing afterwards. Agreed?. IMHO it is not an elegant solution to remove the icons. It might be a better solution to not ship them by default but in a separate package! So the users who don't like repalced icons don't install the extra package and the users who do want a consistent look just install the extra package which sorts the missing icons into the icon structure of the breeze theme... I do agree with miklos that the icons must remain recognizable. But I really prefer a consistent icon look over original icons. |
