Update Concept for Colors and Widgets

Not sure if this is a bug or a feature, but when I assign a color to a widget and then change that color in the color flyout, it asks me to update this color. So far so good. What I do not get however, is why the widget wants to be updates as well now. I did not assign a different color to it, I just changed the hex value assigend to that Color. The way I understand the system, this should not affect the widget? Out of habit I keep updating the widget first and then have to update the color as well. Granted, this is my fault, but why does the widget become updateable in the first place?

I would expect that the widget remains unchanged until I assign a completely new color to it. Are there special cases I have overlooked, that justify the behavior that is currently implemented? If this is just to keep track of unupdated colors I would much rather see a better overview over the colors used in the Project than having the color and widget updates intertwined like this.

:thinking: if I change the color here:

to another one:

and click to update color:

the widget is not changed:

do you mean something different?

It is about changing a color first, update the widget and then change the color again. This could be misleading in some cases, we will discuss it again.

For reference:

A widget with a color assigned to it:

The color is changed and once I hit enter (and by doing so close the flyout once, which easily happens while you work), both the widget and the color want to be updated

After updating the widget, the color still wants to be updated

When you update the color directly without updating the widget first, the widget does NOT demand an update anymore

While taking these screenshots I stumbled across another weird case with this. If I change the color and update the widget, the color still requires an update as described above. If I now revert the color inside the color menu, the widget wants an update. If I revert that as well, the color gets set back to the changed state with the * and wants to be updated or reverted again. If I revert OR update that, the Widget still wants an update or revert. This does not stop until I update both color and widget. This is a bit constructed case allthough I can imagine it to be weird for someone who encounters it by accident.
I do not know if my propsal would improve this and/or create other issues however.

Thanks for the clarification, makes sense now. Would you expect that updating a widget would directly update the color? (might be difficult because you could for example change “Red” in another part of the widget (for example border, another widget cell)). For Antetype they are independent and you are free to store overwritten colors (those with an asterisk) in a widget.

I would have originally expected that the widget does not demand an update at all when I change the hex code of the assigned color. So in the example as long as “red” is assigned to the widget, the widget would not require an update no matter what I set the Hex Code of “Red” to. As I pointed out earlier, it’d be best to think this through since I can imagine that this might cause other inconsistencies. I talked to dominic about this in private already and with his explanation I don’t think the current behavior is a “bug”. The logic is consistent but it can be hard to understand what is going on at times. I discussed this with a colleague as well and he had a similar reaction to me. It is logical but it is not easy to comprehend what is going on. I do not know if my suggestion is the optimal solution or if it might cause other problems.

1 Like

We are glad you brought up this topic. Everything that does not work as expected needs some review.
We planned to allow changing the colors directly in the color-inspector. This way you would not have an unexpected widget-update etc. Would this help in your case?