`Danger`, `Warning`, `Success` alternatives for `Primary` colours

[AlbinoGeek]

The Ask

Perhaps widgets like the ProgressBar and Button could support other colours as defined within the theme?

We currently have the following possibilities:

• Primary being what we use now for HighImportance buttons and progressbar fill
• Background being what we use now for other buttons and progressbar bg

But frankly, I would like us to have these as well:

• Error for (frankly, everything, see below.)
• Danger for both buttons, card border and progressbar fill
• Warning for both buttons, card border and progressbar fill
• Success for both buttons and progressbar fill

These are important both for animation state targets when these can be animated to show the result of the action, as well as showing dangerous action and/or actions that must be taken with care/caution.

Examples

Error

Straight out of Material Design Specification:

[They define a theme colour named Error. This image is also a link to the spec. page.]

For all other colours, also consider the section in the above link called:

Additional colors for data visualization

Danger

This image comes straight from GitHub's Repository Settings page:

[Although to match with current fyne design, only the filled danger (top button) would be implemented.]

There are hundreds of examples of destructive actions, and they should be very visually dissimilar to standard non-destructive actions, from a user experience perspective.

Warning

Can be used:

• as an Animation target
• anywhere the user should be especially cautious, or warned

Examples include:

• Indicating work in progress that is sensitive and therefore should not be aborted or interrupted (yes, you really can communicate all this with just a colour.)
• Card border around potentially-dangerous-but-not-destructive-actions (see Danger)

Success

Can be used:

• as an Animation target
• as an icon tint/colour to show success, or any other indication of success.

Examples include:

• Background colour in a success flash notice (not in material design, because toast messages are sorta deprecated.)
• CI test status icon colour
• Background colour of an already faded-out (pressed and disabled) fades to green to show completion
• + buttons in CRUD interfaces, distinguished from pencil icons / up/down arrows, delete icons, etc
• visual separation inside any sort of dense toolbar (see previous example)

[AlbinoGeek]

Integrating this could help solve/close:

• 1860 - You could set the progress bar to any of these colours. E.g.: in their case, they could have a theme where they used Orange as their Warning colour.

• 1741 - This concept is closely tied to visualization colours.

[andydotxyz]

We already have ErrorColor in the theme.

Adding new colours does not address the suggestion that you could then just have different coloured widgets. All the widgets expose a behaviour/intent based API rather than customisations based on colour or font etc. Therefore we need a way to express the intent through API and handle any additional colours required internally / through the theme only

[AlbinoGeek]

Adding new colours does not address the suggestion that you could then just have different coloured widgets. All the widgets expose a behaviour/intent based API rather than customisations based on colour or font etc.

Totally fair in response to the progressbar issue, however, vvvvvv

Therefore we need a way to express the intent through API and handle any additional colours required internally / through the theme only

Right, and the Theme has support for arbitrary named colours now, and MD specifically mentions that data visualization is a legitimate reason to add custom colours to your theme. As far as I know, we have everything required to support this as of 2.0.0.

If he wants an Orange ProgressBar, he could set it to use the DataVisualization1 Colour he added to his app's theme, etc. (in theory.)

[stuartmscott]

As Andy said it is best not to think of colours, but think of intent and let the widget/theme achieve the intent appropriately. More information is conveyed by telling a button it performs a dangerous action, than telling it to be a certain colour. Consider something like;

button.Importance = DangerImportance

The button can then do smart things like setting itself to be red, and enabling a two-step trigger; tapping button shows a confirmation dialog, tapping confirm performs the action.

[AlbinoGeek]

This is totally fair, and I would 100% agree, if Button was not the only widget to use Importance (if I'm wrong, I apologize.)

If more widgets were aware of Importance, I would totally agree with this approach. However, I could see wanting to mark a number of other widgets as DangerImportance in this example, such as Entry, Card (as shown in the opening post) and a number of other widgets.

While we have ErrorColor right now, you can't easily apply it to widgets (such as, in the MD spec. example, a Card and the Icon held within the Card via "descendant styling" (something else fyne doesn't have at the moment.))

If anything, what @stuartmscott said almost implies that ErrorColor should be ErrorImportance (e.g.: if other widgets supported this.)

---

The way I look at them, Danger, Caution(Warning), Success, Primary and Error are all "States", and we don't have a system/API/funcs to handle those yet semantically.

I am definitely open to discuss this, and am also of the mind (as an end-developer) that "I don't care what it ends up being called, as long as I can use it." -- e.g: whatever the property has to be named, etc.

That being said, as per this discussion so far, it feels like this has to wait until widget.BaseWidget has a concept of State.

---

It's also worth noting that none of the State or Importance approach as described above enables Data Visualization Colours as described on this material design specification path under "Additional colors for data visualization"

---

I suppose this boils down to:

• "Where should a line be drawn between Colour and State?"
• "Who is responsible for State? The Widget?"

[andydotxyz]

If anything, what @stuartmscott said almost implies that ErrorColor should be ErrorImportance (e.g.: if other widgets supported this.)

I think we are talking at crossed purposes. ErrorColor is a theme defined colour, part of the theme API, a proposed ErrorImportance is a hint of user intent on a widget.

I suppose this boils down to:

"Where should a line be drawn between Colour and State?"

The colours will be defined in the theme, the state will be managed by widgets. The package boundary is basically where the line is drawn

"Who is responsible for State? The Widget?"

Yes. Widget API is about state. The rendering details are all hidden away internally.

[andydotxyz]

That being said, as per this discussion so far, it feels like this has to wait until widget.BaseWidget has a concept of State.

I don't think this belongs in BaseWidget as that would enforce every widget to have to handle state changes (3rd party as well). Though some commonality such as another interface, or a standard we follow would be helpful.

It's also worth noting that none of the State or Importance approach as described above enables Data Visualization Colours

Those colours are applied by custom code as far as I know, so they can use the theme directly to look up colour once we have added them as per #1741.