This is how browsers perform color management. They treat
gamma-corrected sRGB colors as if they were linear RGB.
Correctness aside, this mode is introduced for legacy reasons. Most
UI/UX tooling uses this color management as well, and many have created
an intuition about how color should behave from interacting with a
browser.
This feature flag should facilitate application development with `iced`
in those cases.
More details: https://webcolorisstillbroken.com/
...instead of just from function pointers.
I'm making this change not because I actually want to pass a closure,
but to make passing a single fixed function work. This commit also
simplifies the scrollable example slightly, and without the other half
of this change that simplified example fails to compile with:
```
error[E0277]: the trait bound `iced::theme::ProgressBar: From<for<'a> fn(&'a Theme) -> iced::widget::progress_bar::Appearance {progress_bar_custom_style}>` is not satisfied
--> examples/scrollable/src/main.rs:292:28
|
292 | .style(progress_bar_custom_style)
| ----- ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<for<'a> fn(&'a Theme) -> iced::widget::progress_bar::Appearance {progress_bar_custom_style}>` is not implemented for `iced::theme::ProgressBar`
| |
| required by a bound introduced by this call
|
= help: the trait `From<for<'a> fn(&'a Theme) -> iced::widget::progress_bar::Appearance>` is implemented for `iced::theme::ProgressBar`
= note: required for `for<'a> fn(&'a Theme) -> iced::widget::progress_bar::Appearance {progress_bar_custom_style}` to implement `Into<iced::theme::ProgressBar>`
note: required by a bound in `iced::widget::ProgressBar::<Renderer>::style`
--> /home/marienz/src/iced/widget/src/progress_bar.rs:77:21
|
77 | style: impl Into<<Renderer::Theme as StyleSheet>::Style>,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `ProgressBar::<Renderer>::style`
```
This happens because `progress_bar_custom_style` by itself is a function
item, which is typically coerced to a function pointer when one is
needed, but not in this case. It is possible to work around this on the
caller's side, but especially since the compiler diagnostic for this is
a bit rough (see https://github.com/rust-lang/rust/issues/100116) let's
try to make it work out of the box.
