T10243: Some KDE applications could use better icons

Nathaniel Graham noreply at phabricator.kde.org
Sat Nov 2 15:33:24 GMT 2019


ngraham added a comment.


  In T10243#206539 <https://phabricator.kde.org/T10243#206539>, @alex-l wrote:
  
  > Thank you for your replies. As I said I discussed a new icon for Activities time ago but Ivan decided to stay with the 3-dots one. I can't always be around to check that previous decisions aren't overwritten by others. Isn't up to others to check if there were previous discussions on an icon?
  
  
  In any project, every single change can be seen as overriding a previous decision. Like I said, if you want previous decisions to have more weight, you or someone else needs to be around to provide the context, remember the discussion, bring up alternatives, etc. Previous decisions are not self-evident and self-enforcing, especially when the result is something that is problematic or accumulates complaints from users or developers. The hardest decisions to enforce in absentia are those that resulted in an imperfect compromise.
  
  > The one on the Activities icon is somewhere here on Phabricator. Found: https://phabricator.kde.org/M90
  
  Unfortunately Phab search is so horrible that if you hadn't linked to it directly, there's no chance I would have ever found it even if I was specifically looking for it. :(
  
  > The most important rule in my opinion in VDG was: don't change things just for the sake of changing.
  
  This is a strong pet peeve of mine and I agree 100%. As a result, we never do this; every change is because we think the change is a positive improvement.
  
  For example we changed the activities icon because otherwise the icon it was using before was 1) used in other contexts, 2) nondescript and meaningless, and 3) monochrome when we were trying to consistently use colorful icons for System Settings KCMs. This are not "chang[ing] things just for the sake of changing"; those are three good reasons. Maybe the result isn't amazing. I wouldn't say it's my favorite icon either. But doing something for good reasons and failing is not the same thing as doing thing for no good reason, such as because we're bored and restless, because we like changing things around to justify our existence, or because we feel the need to chase design trends. I constantly push back on proposals that I believe originate from one of these reasons.
  
  > In fact the current Dolphin, Gwenview, System Settings and other icons were designed for personal use by me but other VDG members noticed them from my screenshots and asked to submit them, despite the rule of not changing things. It is a matter of attitude: if there is broad agreement to update an icon then proceed. If you are not sure, keep everything as it is, trusting the previous designers who probably took that decision for reasons.
  
  When it comes to app icons, the VDG has in fact settled on a fairly strict guideline for apps that already have icons: don't erode the app's pre-existing branding; just make a Breeze-ey version of the icon. If you do want to make a Breeze icon that's substantially different from the app's existing icon, you need to have a conversation with the app's maintainer and/or developers to formally change the app's official icon to your new icon.
  
  Various Breeze icons violate this guideline, to the point where the apps' developers reject them in favor of the old ones (for example, Okular and Kile). That's ultimately the point of this task: to improve the breeze icons for various apps of ours so that they 1) look better, 2) match the branding guidelines we've set out, and 3) become accepted by the apps' developers.
  
  > One single person who gives the OK to update the icon for a core KDE app? It's the opposite of our previous attitude...
  
  That's a fair point. In general we should probably be more conservative when it comes to approvals. This requires more people with the time and willingness to review patches, of course. :). And node that for the two app icons we have changed so far--Kolf and Kile--we did seek and receive the approval of the apps' maintainers.

TASK DETAIL
  https://phabricator.kde.org/T10243

To: ngraham
Cc: Leon0402, IohannesPetros, alex-l, starbuck, cullmann, IlyaBizyaev, arrowd, abetts, stikonas, knauss, mglb, filipf, mludwig, aacid, lesliezhai, elvisangelaccio, kossebau, trickyricky26, ndavis, yurchor, #kde_games, #ark, #kde_pim, #discover_software_store, #yakuake, #kate, #okular, #gwenview, #konsole, #kde_applications, #vdg, ngraham, cblack, konkinartem, ian, jguidon, hannahk, Ghost6, jraleigh, MrPepe, fbampaloukas, squeakypancakes, alexde, GB_2, crozbo, firef, alexeymin, skadinna, genaxxx, aaronhoneycutt, jriddell, mbohlender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20191102/776ec01e/attachment.html>


More information about the kde-games-devel mailing list