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