Resizable modeless Popup

[nockawa]

Version/Branch of Dear ImGui:

Version: 1.89.2 Branch: Don't know

Back-end/Renderer/Compiler/OS Using ImGuiNet / .net 7 / Windows

It doesn't seem to be possible to have a window created with BeginPopup that can have a Resize Grip so the user can resize it. If it's the case I don't see why this should be a limitation, changing the size of a dropdown could be useful, right?

Is there a way to get around with this? I suppose it would involve relying on Begin but the whole logic of hiding the popup if the user click outside could be cumbersome to implement?

[ocornut]

Which popup(s) specifically are you hoping to resize?

You can call BeginPopupEx() and omit the ImGuiWindowFlags_AlwaysAutoResize flag.

The source for BeginPopup() is:

bool ImGui::BeginPopup(const char* str_id, ImGuiWindowFlags flags)
{
    ImGuiContext& g = *GImGui;
    if (g.OpenPopupStack.Size <= g.BeginPopupStack.Size) // Early out for performance
    {
        g.NextWindowData.ClearFlags(); // We behave like Begin() and need to consume those values
        return false;
    }
    flags |= ImGuiWindowFlags_AlwaysAutoResize | ImGuiWindowFlags_NoTitleBar | ImGuiWindowFlags_NoSavedSettings;
    return BeginPopupEx(g.CurrentWindow->GetID(str_id), flags);
}

[nockawa]

Which popup(s) specifically are you hoping to resize?

Some custom popup of custom controls I wrote. But for instance, there are some GUI that allow resizing the popup of a combobox's list.

BeginPopupEx() is an internal API, so it's not wrapped by ImGuiNet. There's no way I can rely on this. 😔

[ocornut]

But for instance, there are some GUI that allow resizing the popup of a combobox's list.

I made popups movable by default and people often report this as an "issue" because it's not standard, which I personally find odd. On the same logic I agree it'd be better if they were resizable but this would now become technically a breaking change, but it's something we can consider. However in the case of BeginCombo() with an extra level of indirection it may perhaps combo would need an extra indirection.

In case you are looking into specifically vertically resizing a BeginCombo() popup have you looked at the sizing flags of BeginCombo()) ?

so it's not wrapped by ImGuiNet. There's no way I can rely on this. 😔

I think bindings should selectively support parts of imgui_internal.h in a different namespace, I'd suggest to contribute to that .net binding to add extra stuff (if it's not auto-generated).

[nockawa]

The combobox case was just an example. In my situation I've implemented a "DropDown Button" that displays additional content into a popup. This content is filled dynamically, I mean part of it is a treeview with a number of nodes based on the content the user is dealing with. So resizing this window would be nice.

As the flag is about NoSize, I understand it's a breaking change and I dont expect @mellinoe to update ImGui.net with internal, it's based on other projects to interact with the C++.

So I guess the most viable solutions for me are either :

• Forget about it
• Try to implement it with a regular window. This should be possible I guess, I should have to Capture Mouse to detect click outside the Popup to close it and also to prevent interaction with the rest. I will give it a try soon.

[ocornut]

Honnestly I’d think it would be easier and healthier to look into how to amend ImGuiNet when you need it. Even adding that one function may be paving the way to faciliate others doing similar things.

[nockawa]

Healthier, definitely. Easier, I'm sure, at least for me. What I know is I can't dig a deeper hole right now and go for it this way, so I'll just put the idea on a shelve and maybe later on I'll get back to it.

Thank you for your help !

[pixtur]

I encountered the same question today. (Not sure if there is a correlation with pesky ImGuiNet users here). Frankly, I found the decision to permit Popups to be movable but not resizable rather opinionated. I agree that it might seem like an awkward default, but for widgets like the color picker, enabling users to increase its size for situations that require more precision would be very convenient.

[tom-leamon]

I think this issue should be reopened until implemented. It wouldn't be a breaking change to add support via a flag.

[ocornut]

It wouldn't be a breaking change to add support via a flag.

BeginPopup() takes window flags and the "right" direction may be to simply remove ImGuiWindowFlags_AlwaysAutoResize from the default, but for now as mentioned you can call BeginPopupEx().

[tom-leamon]

Ah, I see how that could be considered a breaking change. Using BeginPopupEx works fine for now, but this situation still feels like a possible oversight that could be resolved eventually. I agree with @pixtur that the current behavior seems opinionated, being sort of non-standard. Personally I would have expected it to be non-movable and non-resizable by default, with those being easy to enable via flags.

[ocornut]

One problem is that eg a typical right-click context menu is a popup and it is the most frequent form of popup and we want this to be auto-fitting to menu contents.

[Riztazz]

I believe this question is related, so I’ll ask it here. Is it possible to extend functions like BeginPopupContextItem to accept a third argument of type ImGuiWindowFlags with a default values the same? This would allow for resizable pop-ups when using this pattern.