Closed nockawa closed 1 year ago
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);
}
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. š
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).
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 :
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.
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 !
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.
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?