[WIP] New yakuake logo/icon
Needs ReviewPublic

Authored by mglb on Sun, Nov 3, 1:30 AM.

Details

Reviewers
hein
Group Reviewers
VDG
Yakuake
Summary

Split from: https://phabricator.kde.org/D24621

This is my proposition for new yakuake logo and icon. The logo mixes a
well known terminal symbol (>_) and letter "y".

  • A..E: Main icon propositions.
    • bold logo thickness (3px) is consistent with most logos around (IMO), including breeze adaptations of some KDE and 3rd party applications.
    • thin 2px logo is consistent with original Breeze icons symbols (e.g. utilities-terminal, system-settings)
  • F: Alternative if people really dislike the "y_" logo.
  • G: Logo (style similar to Plasma logo AKA start-here-kde). I guess this is not breeze-icons material, but might be useful somewhere later (or in your mockups), so I'm attaching it.
  • Other combinations of background and logo are possible, especially thin logo on "display" background.

This is how they look with some other Breeze app icons:

Let's choose style(s) first, then we can talk about colors and common
details present on all icons.
My personal preference (most favored first): D, E, A, C

Diff Detail

Repository
R266 Breeze Icons
Branch
yakuake
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 18654
Build 18672: arc lint + arc unit
mglb requested review of this revision.Sun, Nov 3, 1:30 AM
mglb created this revision.

My vote is for A. I love it. It looks like a pull-down terminal just like the parent icon, re-uses the >_ iconography common to our terminal icons, but adds a flair that makes the > look like a Y, conjuring up the app's name. I think this is fantastic.

Adding @hein to the reviewers list, as he's the former maintainer.

ognarb added a reviewer: hein.Sun, Nov 3, 3:08 PM
ognarb added a subscriber: ognarb.
ndavis added a subscriber: ndavis.Sun, Nov 3, 6:55 PM

A or C for me.

A looks more like how I imagine a "drop down terminal", but it's got a lot of margin below the bottom of it.

I tried seeing how it would look extended down to the bottom margin:

C looks more like a pull down projector screen, but that's not necessarily bad. It also doesn't quite reach the bottom.

I tried seeing how it would look extended down to the bottom margin:

VDG, Should we allow some types of icons to be vertically off center? If not that, should we allow some icons to not reach all the way to the top and bottom margins? There are already some icons like that, but that doesn't necessarily mean we should want that.

VDG, Should we allow some types of icons to be vertically off center? If not that, should we allow some icons to not reach all the way to the top and bottom margins? There are already some icons like that, but that doesn't necessarily mean we should want that.

I don't think we should allow vertically off-center icons. The only reason to do this is to align the baselines of all icons, but that's only useful for horizontal rows of icons and looks bad with vertical columns of icons or anytime an icon is put within a container that is centered.

I recently fixed a bug report about non-centered icons that shows the problems arising from this: https://bugs.kde.org/show_bug.cgi?id=393550

mglb added a comment.Mon, Nov 4, 3:18 AM

I tried seeing how it would look extended down to the bottom margin:

Breaking nice-looking proportions just to fill vertical space is not good IMO. Making the bar a bit higher might make it look more reasonably. Your second proposition (icon C) looks nice though.
I agree with vertical alignment - I'll fix it.

If not that, should we allow some icons to not reach all the way to the top and bottom margins? There are already some icons like that, but that doesn't necessarily mean we should want that.

Note that size is perceived differently on different shapes - compare e.g. square and circle - with the same logical sizes, circle looks smaller (Breeze has this problem).
The icon C is 48px wide (44px when counting only the screen), so 36px (38px with "handle" on the bottom) height makes its sizes visually similar to 40x40px square icons.

The same applies for alignment (see e.g. plasmadiscover.svg), but that shouldn't be a problem here.

ndavis added a comment.Mon, Nov 4, 4:01 AM
In D25123#558353, @mglb wrote:

Breaking nice-looking proportions just to fill vertical space is not good IMO. Making the bar a bit higher might make it look more reasonably. Your second proposition (icon C) looks nice though.

I agree, the modified A didn't turn out that well.

Note that size is perceived differently on different shapes - compare e.g. square and circle - with the same logical sizes, circle looks smaller (Breeze has this problem).
The icon C is 48px wide (44px when counting only the screen), so 36px (38px with "handle" on the bottom) height makes its sizes visually similar to 40x40px square icons.

The same applies for alignment (see e.g. plasmadiscover.svg), but that shouldn't be a problem here.

I'm aware of that. I know Material Design uses different sizes for circles, squares and rectangles for that reason. Unfortunately, switching to that system means we would need to change many icons. I believe the reason why we use the system we use is because of horizontal text alignment, but I think that matters more for monochrome icons than color icons. On the other hand, nothing actually lines up with text in a way that stands out as lining up particularly well whether you choose 10, 11 or 12pt Noto Sans.

mglb updated this revision to Diff 69507.EditedSat, Nov 9, 8:00 PM

switching to that system means we would need to change many icons.

Let's just keep this in mind when making new icons. At least when it doesn't stand out too much, i.e. we shouldn't make new square icons smaller than other square icons just to match circles, but also don't try to fill all available space when there is no need to.

I've aligned icons vertically. There are two new varians of "A":

  • A1 - Uses all available space, with larger top bar
  • A2 - Folder-icon sized, also with larger top bar. Dolphin/folder, system-run, and some other rectangular icons do not use full available area, even though they could just by scaling them up proportionally - they have 4px side margins and 6px up/down margins.

A, A1:

A2, C:

ndavis added a comment.Sat, Nov 9, 9:00 PM

I think I prefer C the most now that I've seen it next to other icons. It has a similar level of detail to other Breeze icons.

GB_2 added a subscriber: GB_2.Sat, Nov 9, 9:01 PM

I think I prefer C the most now that I've seen it next to other icons. It has a similar level of detail to other Breeze icons.

+1

Agreed, C for me too.