Tooltips of disabled widgets are hard to read because of transparent background

[DanielGibson]

Version/Branch of Dear ImGui:

Version 1.90.7

Back-ends:

imgui_impl_sdl2.cpp + imgui_impl_opengl2.cpp (probably all)

Compiler, OS:

Linux + GCC 11.4 (probably all)

Full config/build information:

No response

Details:

Widgets that are disabled (with ImGui::BeginDisabled()) can still show tooltips when hovered.
This is great, for example to indicate why they're disabled.
However, the background of those tooltips is very translucent, so whatever is under it becomes visible. Especially when there's text under the tooltip, it's hardly readable at all, see screenshot below.

I think that the tooltip background should always be opaque enough so its text can be easily read; probably it should look the same for enabled/disabled items, or otherwise maybe have a gray background (but still with high enough alpha value)

Screenshots/Video:

Tooltip of a disabled button:

For comparison, tooltip when button is not disabled:

(Please excuse the ugly handdrawn cursors, for some reason the real cursor wasn't on the screenshots)

Minimal, Complete and Verifiable Example code:

// Here's some code anyone can copy and paste to reproduce your issue
ImGui::Begin("Example Bug");

ImGui::BeginDisabled();
ImGui::Button("Disabled Button");
ImGui::SetItemTooltip("The tooltip text of the disabled button. This button has been disabled just for demonstration purposes.");
ImGui::EndDisabled();
ImGui::Text("Some text under the disabled button. Sometimes you just want some text under a button, you know?");
ImGui::Text("Could even be multiple lines of text! There's so much text in the world, you wouldn't believe it!");
ImGui::SeparatorText("Or even a Separator with text!");

ImGui::End();

[ocornut]

Thank you. I agree this is an issue.
I am a little surprised this hasn't been caught before. Our demo code call the tooltip after EndDisabled().

In general, I think nested windows that are not child window shouldn't inherit disabled-ness:

ImGui::Begin("Example Bug");
ImGui::BeginDisabled();
ImGui::Begin("Nested window call");
ImGui::End();
ImGui::EndDisabled();
ImGui::End();

[ocornut]

This is now fixed/supported with f953ebf !
Also added a test ocornut/imgui_test_engine@ac5b5ed

(The "misc_recover" test is also useful for this, for simplicity I had to amend ErrorCheckEndWindowRecover() with a tweak because StackSizesOnBegin.SetToContextState(&g) is set before calling internal BeginDisabledOverrideReenable(), but this could be reworked.)

[DanielGibson]

Wow, that was quick, thank you very much! :)

[d-musique]

In general, I think nested windows that are not child window shouldn't inherit disabled-ness:

@ocornut Thanks, but non-inheritability of disabled status for root windows can be a drawback.
Specifically, I wish that higher-level framework code would be able to control the overall disabledness, indepently of how a user would implement the frame call. (such that I may implement a setEnabled(false) similar to QWindow)

ImGui::BeginDisabled(uiReadOnly);
// user's UI code, might be implemented in a virtual somewhere else
ImGui::Begin("Main"); // does not get disabled

[ocornut]

I don’t understand your message.

[d-musique]

I don’t understand your message.

My bad. Before I'm opening an issue, let me try to ask this more clearly:
would it be acceptable to have a global Disabled flag that applies to all RootWindows created under it?

(The flag DisabledOverrideReenable from the related PR specifically prevents this, and there is apparently not a solution around this)

[ocornut]

It’s mostly a problem of how to design an api for it, but we could provide a bool in imgui_internal.h to provide the features without a public api.

[d-musique]

It’s mostly a problem of how to design an api for it, but we could provide a bool in imgui_internal.h to provide the features without a public api.

Frankly, I'd be happier if the DisabledOverrideReenable just would only kick in on the basis of the ImGuiWindowFlags_Tooltip flag presence, instead of checking it to be a root window.

This would let a programmer free to have both worlds ; global, local to that specific window, or however user is choosing to structure their code.

Currently, documentation text of the Disabling API in imgui.h do not mention root windows being a special case.

Thinking about it, a Root window is also an interactive element (collapse button, scrollbar..).
Then doesn't it make sense for it to be possible to Disable?

[ocornut]

@d-musique I am not sure it is practical or even functional to use this way. Our current disabling setup increases alpha for everything, which looks remarkably odd on a transparent window. It is also currently possible to move the window, which may or not be a bug.

Can you clarify how/why you are using this property?

[ocornut]

I have currently applied suggested logic (with dd5c30d) but I am still a bit undecided and would like further inputs on this.