D16421: Improve emblem contrast, legibility and consistency

Noah Davis noreply at phabricator.kde.org
Sat Oct 27 01:38:22 BST 2018


ndavis added a comment.


  In D16421#349075 <https://phabricator.kde.org/D16421#349075>, @bruns wrote:
  
  > @ndavis - can you upload the `git format-patch -1` output somewhere (temporary)?
  
  
  https://hastebin.com/egepiwurab.diff
  
  > There may also be a conceptual issue here - previously, the `emblem-locked` which is used for unaccessible (e.g. root owned) files was a lock with orange background, now it is green. For locked encrypted files green may be suitable, for unacessible files not so much.
  
  You're right. Perhaps we should introduce some new emblems?
  
  Some ideas:
  
  `emblem-select` (`emblem-added` sounds like it should be used for things that were successfully added)
  `emblem-deselect` (in some contexts, `emblem-remove` would be destructive)
  `emblem-encrypted-locked` (to match the existing `emblem-encrypted-unlocked`, Papirus has this)
  `emblem-readonly` (Papirus has this)
  
  Here's a list of emblems from the Papirus theme: https://hastebin.com/asuquwoyap.css
  I'm not saying we should use all of these, but we can use that list to pick compatible names and having icons that match the context is a good thing.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D16421

To: ndavis, #vdg
Cc: bruns, ngraham, bcooksley, kde-frameworks-devel, #vdg, michaelh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181027/4033ff6a/attachment.html>


More information about the Kde-frameworks-devel mailing list