App icons require shaping at every callsite

Do we have some code examples? Where do app icons come from? I don't know how consistent the path is… doing magic on arbitrary path names may or may not make it even more confusing when the outcome changes depending on the image.

If a usability researcher saw eight users making the same kind of mistake when using an Ubuntu phone, the researcher might make a suggestion for how to fix the design flaw, but finding the best solution would be the platform design team's responsibility. Here, I've given you eight examples of engineers making the same kind of mistake when using the APIs. I've made one suggestion of how to fix the design flaw, but finding the best solution is the SDK team's responsibility.

FWIW I was just discussing this with Benjamin Keyser, and he said (paraphrasing), "Why not rename those properties to something like isAppIcon? Then you wouldn't have to remember that app icons get frames and others don't, you're just being asked whether it's an icon for an app."

That would raise the API quality from roughly "Read the implementation and you'll get it right" to roughly "The name tells you how to use it" -- roughly, because the property is optional so engineers might still err by omission. I'm sure dedicated API designers can do better than Benjamin or I can. ;-)

The preliminary conclusion is to leave this out of the new API - the current ListItem is going to be deprecated because it's by design very slow. The built-in shape feature is actually one of the reasons for that. And it looks to be the minority of use cases that require a shape at all.

14:33 <zsombi> kalikiana: the new ListItem does not have any shape, whatever you put in it that will eb shown, no predefined layout, nothing
14:34 <zsombi> kalikiana: all we have are layout helpers, like ListItemLayout, which is only a GridLayout with 2GU marging left/right
14:34 <kalikiana> zsombi: hmm would it make sense to have an app layout for that?
14:34 <zsombi> kalikiana: it won't be flexible enough...
14:35 <zsombi> kalikiana: the idea is that you could have an icon or an image there, framed or frameless
14:36 <kalikiana> zsombi: yeah that's what I'm wondering. it's tedious to hunt down the exact use cases… it may not even make sense to have a standard way of doing it, many of the bugs right now are due to the default being true which is almost always wrong
14:37 <zsombi> kalikiana: right. And if you don't need frame, meaning teh image/icon should not be in a Shape, then we'd have a dangling Shape component which is not visible but its initialization time eats performance...

Christian, I fully agree that shaping icons shouldn't be part of a list API. It's nothing to do with lists; for example, developers often need to use app icons in splash screens or About screens.

But that doesn't address this bug at all. The bug here isn't "List item icons usually have inappropriate frames", or even "App icons require shaping in every list item". It's "App icons require shaping at every callsite". For example, imagine you reimplemented the "Updates" list using the new list API. How would the app icons get a frame around them? Would it happen automatically, or would it be something you have to remember to do? If it's something you have to remember to do, this bug is still valid.

The problem is that "app icons" are not a technical concept. "The" icon of a particular app comes from its .desktop file from its installation folder, and at the end of the day will have an arbitrary filename looking like any other image. Click packages can have multiple unrelated images and more than one app.

How about an AppIcon component?

I think you just described how to fix the bug. :-) If the "icon of a particular app comes from its .desktop file from its installation folder", then the way Ubuntu should tell whether it should shape an arbitrary icon is by checking to see if it is one of the icons listed in the .desktop file in its installation folder. If Ubuntu can do that, then an app developer (or Ubuntu contributor) won't need to remember to use an AppIcon component or anything else.

Unfortunately that's rather backwards as it means tentatively looking for .desktop files in the same folder, all parent folders, all sub folders and parsing any .desktop that may be found, for every single image opened - when the app had to have done this, more efficiently, wherever the icon paths came from in the first place, this is why I was originally asking "Where do app icons come from?", because there information is there, but lost.

Okay, so maybe it's impractical to reach the "It's impossible to get wrong" level. But your AppIcon component suggestion would at least get us up to the "The name tells you how to use it" level.

Eighteen months later, new cases have appeared where app icons are incorrectly rendered with unrounded corners: indicator-messages and indicator-sound.

Meanwhile, bug 1449295 is another example of the harm of not implementing this: engineers are trying to remember all the places that render app icons, so that they can make transparent app icon backgrounds opaque in all of those places. That’s a waste of time, and odds are at least one callsite will be forgotten. If app icons were a toolkit element, fixing that element would fix the problem everywhere.

Status changed to 'Confirmed' because the bug affects multiple users.

let's discuss in the next SDK meeting. It would be a good thing to perhaps have an "appIcon:true/false" property of the Icon component, or an appIcon component - which apply the ubuntuShape on the icon by default.

The sharp corners on app icons are something that are not our visual style