Changed ui.disable() to modify opacity.

[tye-exe]

It previously tinted elements, which could have lackluster effects.

• Closes Disabled image button doesn't fade out in light mode #5850
• I have followed the instructions in the PR template

New looks

(I say new but I tried to keep them as similar as possible to previous)

Light mode

light_mode.webm

Dark mode

dark_mode.webm

Additional remarks

Since the opacity is being change, elements that are on-top of other elements now show some of the underneath element (this can be seen with the slider in the sent videos).

[juh9870]

This has far-reaching consequences for the visual of existing egui apps other than just fixing the linked issue.

I think this change should be configurable; otherwise, significant considerations should be put into messing up existing visuals.

[tye-exe]

That's a fair viewpoint.

What other possible solutions to this issue do you recommend?

I tried modifying the fade_out_to_color method (as also suggested in the issue) to modify the alpha channel. However, this was not able to prevent the issue on light mode, even at the extremes of the alpha channel.

Relevant method:

egui/crates/egui/src/style.rs

Lines 1055 to 1060 in 5d6aaa2

	/// When fading out things, we fade the colors towards this.
	// TODO(emilk): replace with an alpha
	#[inline(always)]
	pub fn fade_out_to_color(&self) -> Color32 {
	self.widgets.noninteractive.weak_bg_fill
	}

Out of interest in which situations will this be an issue for (so I could potentially work on solving them)?

[juh9870]

The problem is exactly what you mentioned in the Additional remarks sections.

I believe that a method of fading out (color or transparency) should be an option in the style. Maybe as an enum variant akin to

enum FadeOutMethod {
    NonInteractiveWeakBgFill,
    CustomColor(Color32),
    DimTransparency(f32)
}

the exact shape of variants and naming should be discussed ofc

[tye-exe]

I agree with being able to override the fade out colour, but that does lean towards a more major change, as Visuals is a commonly used data structure.

Also adding more default colours increases the maintenance burden in the future. i'm not sure if that would be needed if the user can customise the fade out colour.

[tye-exe]

A possible option for setting a custom fade out colour would be to add a feild like override_fade: Option<Color32>, which can default to None.

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/6765-defaultaffectsopacity
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

[emilk]

We should also remove Visuals::fade_out_to_color too, and replace it with fn fade_out_opacity(&self) -> f32 { 0.5 } and use it for Visuals::gray_out

[tye-exe]

Would it be best to deprecate it or completely remove it?
If so what should the deprecation message be?

[tye-exe]

Would it be best to deprecate it or completely remove it? If so what should the deprecation message be?

I chose to remove it completely as there was no other calls to it.

[tye-exe]

Will it be a good idea to add an attribute to Visuals that is returned from fade_out_opacity?

Because currently the value is hard-coded, so it cannot be changed.

[tye-exe]

I have added the option for user-customization that i suggested & created a pull request against the branch in my fork for anyone to look at.

I can easily merge these changes into the branch in this egui pull request.