Reduce emblem size for very small icons to prevent obscuring too much of the icon
AbandonedPublic

Authored by ngraham on Sep 30 2018, 9:40 PM.

Details

Reviewers
None
Group Reviewers
Frameworks
Dolphin
VDG
Maniphest Tasks
T9740: Improve disk presentation in the Places panel
Summary

A single icon's emblem can take up 25% of the total icon area in certain cases, which obscures enough of the icon that it may become hard to tell what it is. This is especially noticeable with 16x16 and 32x32 icons in Dolphin's Places Panel. See T9740#162147 for examples.

Because an icon can have up to four emblems, it is theoretically possible for a small icon with four emblems to show none of the icon itself, just emblems!

This patch adjusts the calculation so that a single emblem never takes up more then 18.75% of the total area of an icon, even at small sizes. As a result, icons are less obscured by their emblems.

Test Plan

Dolphin Places panel:

Default: Small icons (16x16):

Medium icons (22x22):

Large icons (32x32):

Huge icons (48x48):

[images depict the new hard drive icon introduced with D15853]

Diff Detail

Repository
R302 KIconThemes
Branch
smaller-emblems-at-small-sizes (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 3376
Build 3394: arc lint + arc unit
ngraham created this revision.Sep 30 2018, 9:40 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptSep 30 2018, 9:40 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
ngraham requested review of this revision.Sep 30 2018, 9:40 PM
ndavis added a subscriber: ndavis.Sep 30 2018, 11:40 PM

The emblem for the 16px version is too small to read. What if instead of the emblem being on top of the icon, it was off to the side? Then it wouldn't matter what size the emblem is as long as it looks good where it is.

broulik added a subscriber: broulik.Oct 1 2018, 8:04 AM

Did you test this with other icon sets, such as Oxygen? It may work with SVG ones but not pixel-based iconsets. Oxygen only has 8x8 emblems.

The emblem for the 16px version is too small to read.

Did you test this with other icon sets, such as Oxygen? It may work with SVG ones but not pixel-based iconsets. Oxygen only has 8x8 emblems.

It seems we have a problem, then:

  • 8x8 emblems take up 25% of a 16x16 icon's space, rendering the icon difficult to distinguish
  • 6x6 emblems are unreadable and/or look bad (for raster icons that get scaled)

Suggestions?

What if instead of the emblem being on top of the icon, it was off to the side? Then it wouldn't matter what size the emblem is as long as it looks good where it is.

You mean like this?

[Icon] [emblem] Label
ndavis added a comment.Oct 1 2018, 3:29 PM

You mean like this?

[Icon] [emblem] Label

Yes, like that.

Hmm, that would only make sense for small icons. If we implement it for small icons but keep the overlay style for larger icons, then there will be an odd change if and when the size is increased, and the label will jump horizontally. Also, since this patch is for KIconLoader, it would affect more than just Dolphin's Places panel; such a change would also affect list views in Dolphin and the file dialogs when using small icons. Not sure that would be a good idea.

I wonder if maybe we should redesign the emblems that currently have a white symbol inside a colored background shape so that their 8x8 versions are just a colored symbol with no background shape. The idea would be to remove both some of the visual complexity that can get lost at small sizes and also the large background that obscures so much of the icon.

If we do that, for the smallest icons it might be feasible to keep the emblem sized at 8x8 because they would be more visually clear and obscure less of the icon.

Thoughts?

cfeck added a subscriber: cfeck.EditedOct 1 2018, 8:33 PM

The emblem conveys important information; it should be clearly visible. Scaling to size 6 or 12 would only make sense if our icon sets ship those sizes for emblem icons.

The emblem conveys important information; it should be clearly visible. Scaling to size 6 or 12 would only make sense if our icon sets ship those sizes for emblem icons.

I would argue that at 8x8, it's really hard to understand what some of the emblems are or mean. This is especially true of the mounted and unmounted emblems that we're talking about for the purpose of the Places Panel (see T9740).

The icon also conveys important information and should be clearly visible. The problem here is that currently, the emblem can take up 25% of the icon's area when the icon is 16x16 or 32x32, which can render the icon itself difficult to distinguish. For icons that don't use the full space, the emblem can take up even more space.

For example here's an 8x8 size emblem on top of a 16x16 size icon that doesn't use all of its available space:

That's just visual gibberish.

It's a hard problem to solve unless we put on our thinking caps and come up with some genius idea. :)

What are the different possible emblems that can be applied automatically by the mount process?

What if for small sizes, we just use simple shapes and colors. Like a green circle for mounted, and a yellow triangle for something else, and a red square for another state?

I mention combining shapes and colors, for those who are color-blind.

It's possible to have tiny symbolic emblems that still convey information. Here's a screenshot from my Dropbox folder in Dolphin, with 16x16 icons plus the tiny little emblems that Dropbox adds:

Those emblems are technically 8x8, but the outermost pixels nearly transparent, so they're essentially 6x6. Since they're round rather than square, even more of the base icon is visible. Yet they're still perfectly distinguishable.

Perhaps all that's needed here is to make the emblems a bit smaller within their 8x8 box, and to round the corners of the square ones more.

cfeck added a comment.Oct 1 2018, 9:51 PM

I would prefer that.

ngraham abandoned this revision.Oct 14 2018, 4:06 AM

No longer needed with D15935 (or at least, the pressure is off).