Read-only / Disabled widgets

[heroboy]

No description provided.

[andoma]

+1 on this, currently i just decrease alpha to make it look disabled but widgets still respond to events (obviously). Would be nice to have this built-in

[ocornut]

Which widget in particular are you using it for?

[andoma]

Typically sliders and buttons

vs

(this is with adjusting global alpha)

[ocornut]

Probably rather low-priority.
There's two aspects to it - the interaction and the rendering.
The interaction is probably easy to sort out. Outside api to be based on PushButtonRepeat()/PopButtonRepeat() (storing a bool + a stack) and check it in the right spot.

The rendering side is more work because we ought to decide on the design here, how are disabled state represented in general, how it can be part of the theme in a sensible lightweight manner without adding dozens of new entries into the theme system that the user would have to manipulate. Perhaps the theme system can compute certain colors based on HSV space operations and store that so widgets code don't have to do those calculation. e.g. we'd have a Colors[] array and a ColorsDisabled[] array that's auto computed. This tie somehow with some of the ground toward a potential new design (#184).

For now I suppose we could add the feature as affecting interaction only, probably wouldn't hurt but it would have to be documented as "visuals will change in a future version".

[andoma]

Just the interaction-parts is perfectly sufficient for me.

Btw, thanks for all your awesome work on this.

[Pagghiu]

In our software I've been handling the disabled state myself, "wrapping" existing imgui calls.

[ocornut]

Some notes. Are you looking for a "InteractionDisabled" or "EditDisabled/Readonly" flag ?

• Text box must still be selectable / copiable into clipboard.
• Scrollbar must be active? e.g. scrollbar of a listbox, of a child?
• How about tree nodes and collapsing header?
• Do we allow sliders and drags to be ctrl+clickable to be turned into a read-only text input?
• How about the mouse hovering feedback on drags (currently the background is highlighted).
• How about columns separators?
• How about buttons? If the flag is called ReadOnly vs Disabled how we expect that button works?
• Do we need separate Disabled and ReadOnly flags?
• What do IsItemHovered() returns?

[heroboy]

I think "Disable" means disable all child widgets including the scrollbar, and preventing all mouse interactive.
And only a few widget has "Readonly" flag. Readonly widget can interact as normal, but the content will not be changed.
And now the readonly can easily implement in application level, for example:

float tmp = x;
ImGui::InputFloat("xxx",&x);
x = tmp;

I think this is good, because windows controls act like this.

[ocornut]

I think read-only should be global and inherited as well, so you can easily turn an entire block into read-only and still, scroll and copy data. That solution above a bit a hacky and would show an edit flicker before the revert, it's not really satisfying enough.

[benvanik]

@ocornut agreed - having something similar to button repeat would be nice. It'd also prevent the need for a bool disabled/bool read_only/etc on everything.

I was just running into this myself needing both read-only content and separately fully-disabled UI (no input/greyed out/etc). My hacky solution in lieu of a real one is to filter some of the mouse events in broad regions before handing them to imgui and to draw a giant semi-translucent rect over everything at the end. It's nasty :)

[ocornut]

Alright,

I have added a ImGuiInputTextFlags_ReadOnly flag to InputText() / InputTextMultiline() as an exception because I think it is a more common use case (to make blobs of text more naturally copiable, even though you can use the logging api for that too).

We need different flag for Disabled and global- ReadOnly. Earlier is easier to implement, later probably a bit more work, as we need to dig a little more inside widgets to make sure things like IsItemHovered() works but the widget doesn't react. So probably will add Disabled early on. It will have to be documented as "unfinished" because it won't affect the visuals just you but it WILL in the future.

[ocornut]

There's another usage pattern which I found useful in one app I made, which is to have widgets that looks disabled but are active. Here I have a set of variables that can be overriden. You can click the override checkbox but you can also directly click on disabled-lookin widget on the right-side and it automatically set the override flag as you click them. That's easily done with just changing text color.

Probably won't affect this task here, but I wanted to share that it may be also a viable idea in some cases.

[ocornut]

@haddock07 in #330

Is there a way to disable a widget (shown but with a disabled state)?
For example, I would like to have a check box, in a disabled state, where it couldn't be activated or hovered, and displayed with a darker color. Of course, the function ImGui::Checkbox would always return false.
I did a workaround by setting the same color for the 3 states (normal, hovered, active), but when the user clicks on the check box, the check mark is actually shown one frame before returning to the unchecked state.

[r-lyeh-archived]

Hey,

I was looking for possible CheckboxDisabled()/RadioDisabled()/MenuItemDisabled() widgets and found this thread instead. I guess I may share some feedback.

Rather than multiplexing the workload into infinite disabled widget variants that may be (very) time consuming, my suggestion would be rather to create a single BeginDisabled()/EndDisabled(); group that pushes disable state into the stack. From this point:

a) I would expect to be able to browse still the disabled group (scrollbars and tooltips would be active), but not able to interact with any variable modifier at all (checkboxes, selectables, combos, input boxes and so on). Ie, all sub-widgets that may change the user variables shall not react to keyboard/mouse events (ever); any other will. So all my widget values are safe (constant) inside a disabled stack.

b) I would expect the rendered widgets would look similar to a blended widget+background. Achieved either by blending every sub-widget with alpha *0.5, or by doing fancy HSV to blend every rendered color with the background color.

Keep up the good work!

Edit: PS: you could store all the disabled colors variants (the (HSV+color background)/2 thing) when applying styles, so everything would be "cached" in anticipation.

[teamimx]

+1 on the general idea of a disabled state :)

[leftspace89]

master...leftspace89:master

thx for information :)

[ratzlaff]

@leftspace89 By chance, could you make a patch instead of a series of images?

[sonoro1234]

+1 on the general idea of a disabled state :)

[qimmer]

+1 on the general idea of a disabled state

[codecat]

Any update on this?

[ldecarufel]

I'd just like to chime in and say that I also would like a way to disable groups of controls.

Maybe PushDisabledState()/PopDisabledState() functions would be the best, since it follows ImGui's stack-based approach.

Maybe disabled controls could simply be drawn in the monochrome version of their regular color, multiplied by a predefined color in the styles.

[r-lyeh-archived]

I just hacked it from ideas in this thread.
Hovering, tooltips and input texts work as expected when disabled.

namespace ImGui {
    std::vector<float> alphas;
    void PushDisabled( bool disabled = true ) {
        alphas.push_back( GetStyle().Alpha );
        GetStyle().Alpha = disabled ? 0.25f : 1.0f;
    }
    void PopDisabled( int num = 1 ) {
        while( num-- ) {
            GetStyle().Alpha = alphas.back();
            alphas.pop_back();
        }
    }
    // Install: edit ImGui::IsMouseHoveringRect() and change return to:
    //   return rect_for_touch.Contains(g.IO.MousePos) && (GetStyle().Alpha >= 1);
}

[neclepsio]

When do you plan to make it stable?

[azchatlanin]

How to deal with it? If you make the button inactive when you press it!

static bool button_disable = false;
if (button_disable) ImGui::BeginDisabled();
if (ImGui::Button("OK", ImVec2(120, 0)))  { button_disable = true; }
if (button_disable) ImGui::EndDisabled();

[codecat]

Just pass your disabled state to BeginDisabled:

static bool button_disable = false;
ImGui::BeginDisabled(button_disable);
if (ImGui::Button("OK", ImVec2(120, 0)))  { button_disable = true; }
ImGui::EndDisabled();

(Sorry, edited after I checked the documentation again 🙃)

[Xeverous]

Hello, I'm reviving an old issue (not sure why it is still open) because I noticed a regression in my project after updating the library.

Git bisect told me fb4bbeb is the first bad commit and this is the issue: I was intentionally following many disabled widgets with if (ImGui::IsItemHovered()) { ... } to showcase on-hover tooltips to explain why these elements were disabled (or any other related information).

if (ImGui::BeginMenu("Menu")) {
	ImGui::MenuItem("A disabled option", nullptr, false, false);

	if (ImGui::IsItemHovered()) {
		ImGui::BeginTooltip();
		ImGui::PushTextWrapPos(ImGui::GetFontSize() * 35.0f);
		ImGui::TextUnformatted("An explanation why it is disabled");
		ImGui::PopTextWrapPos();
		ImGui::EndTooltip();
	}

	ImGui::EndMenu();
}

How can I implement such behavior after the linked commit?

[cfillion]

ImGuiHoveredFlags_AllowWhenDisabled or more generally: IsItemHovered(ImGuiHoveredFlags_ForTooltip) (v1.90+). Since 1.89.7 there's also a helper function for the common IsItemHovered+BeginTooltip pattern:

ImGui::MenuItem("A disabled option", nullptr, false, false);
if(ImGui::BeginItemTooltip()) {
  ImGui::PushTextWrapPos(ImGui::GetFontSize() * 35.0f);
  ImGui::TextUnformatted("An explanation why it is disabled");
  ImGui::PopTextWrapPos();
  ImGui::EndTooltip();
}

Since v1.89.4 the return value of BeginTooltip should be checked.

[ocornut]

Closing this, indeed there's no reason to keep this open. This is the 8th oldest open issue :)

FYI i don't yet have a good implementing for SetNextItemDisabled() (it's quite tricky for obscure reason), but I'll eventually will.