Access icons by names that describe the icon image

[chran554]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

First of all, this is a minor feature enhancement.

I use the built in theme icons in my applications and ost of the time it work out fine.
But I have one consideration and that is that the icons are referred to their, picture independent, action or concept name.

A lot of times this is exactly what I want. For a confirm-button an icon that illustrates a "confirm" action by an image of a "checkmark". If the themes would update or the icon for the "confirm" action would for some reason, for example change to a "thumbs-up" image. It would all be fine for my confirm-button, as my application would update with the theme.

However for some buttons, menu items or icons used in the application etc I would really like the icon to be set to what the actual image depicts.
For example if I had built an app for a TODO list with checkmarks for all my finished tasks I would not like to have those updated to "thumbs-up" images. This is where I can have good use for icons that are referenced by what they actually depicts.

Is it possible to construct a solution with the existing API?

Create your own icon resource from downloaded fyne svg-image. Or draw your own image.
But they might deviate from future theme updates over time.

Describe the solution you'd like to see.

Add theme icon entries with names that states what they actually depicts. (Keep the theme concept or action related icon entries as well.)
For example: Add a icon.CheckMarkIcon() (and keep the theme.ConfirmIcon()).

Thoughts:

• Place the icons that are referenced by names that describe what they really depicts in a "icon" package, to differentiate them from the "theme" icons.
• Use the new icons to define the theme icons(?)
  func ConfirmIcon() fyne.Resource { return icon.CheckMarkIcon() }
• Let the icon image filenames state what they depict.
• The icons in the icon package can still be updated in theme style but not change in what they depict.
• The icons in the theme package can be updated in content, illustration and/or style, as long as they stay true to illustrate action or concept.

[andydotxyz]

I don't really understand this to be honest. The theme API is about an abstraction so that app developers can drop whatever assets seem appropriate inside.
Won't naming the icon by content instead of intent break our semantic API design?

For example if I had built an app for a TODO list with checkmarks for all my finished tasks I would not like to have those updated to "thumbs-up" images.

For this use-case wouldn't you use the Check widget, or the icons that are used to represent checks. I don't understand where thumbs-up comes from.

[chran554]

I am sorry if I did not make sense in my text. I'll try to rephrase myself.

I am not suggesting that you should change the naming or remove any of existing icons in the theme package.
I suggest that you create yet another set of icons in a icon package where the icons are named by content.

That way you keep your semantic API design for icons AND allow for developers that would like to use the "waterdrop"-icon, for whatever water app related reason, within their app. They can use the waterdrop icon with confidence that icon.WaterDropIcon() always stay a waterdrop by content and be kept in style with the other theme icons used by fyne widgets.

Your semantic API design is free to evolve and change content of theme.ColorChromaticIcon() if you find a better icon that suit your intention or theme, for example say a colorwheel. (This can be done without breaking any developed applications that otherwise might been tempted to use the ColorChromaticIcon, for the waterdrop image in their water application.)

(I hope I made more sense with this example and that I understood your use of "semantic API design" correct.)

[andydotxyz]

Thanks, I understand this now - but won't it just lead us to having to maintain old icons where we change the one used in the main package?

It feels like this might be the job for a separate package (one that Fyne may choose to use internally but would not be part of our public API).
I'm not sure how it differs from grabbing the icon and putting it in your app directly - but I could still be missing something.

[chran554]

Thanks, I understand this now - but won't it just lead us to having to maintain old icons where we change the one used in the main package?

The way I see it fyne can update/maintain all of the old icons (if you change the theme style of the icons, there is still a change in fashion for icon layout over time). So yes, there will be some additional icons to maintain over the ones you already make use of in the default theme. On the flip side, applications that rely entirely on your icon library will have consistent icon updates in their applications when they update their fyne version.

It feels like this might be the job for a separate package (one that Fyne may choose to use internally but would not be part of our public API).

Sure

I'm not sure how it differs from grabbing the icon and putting it in your app directly - but I could still be missing something.

See the "flip side" comment above. :)

[andydotxyz]

So yes, there will be some additional icons to maintain over the ones you already make use of in the default theme.

This would require all apps to be carrying dead assets in their build which is just wasted space and slower downloads.

On the flip side, applications that rely entirely on your icon library will have consistent icon updates in their applications when they update their fyne version.

But our API only exposes behaviour and intent - not specifics. Just like you can't expect that "ShadowColor" is dark grey or "Primary" is blue.