-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting max/min size of windows while docking? #2849
Comments
Hello, As discussed in #2690 it is hard to provide such feature completely. By definition multiple windows can be docked in the same spot and they may have conflicting constraints. It is unclear what the problem is in your GIF though: why do you need to setup such constraint? I can think off of a few ideas: (1) We support per-window constraint and the visible window applies its constraint to the docking node. I can envision three problems: (1-A) selecting another tab or making a new window appears could make all the docking node changes size which will be very strange and confusing. (1-B) The preview displayed when using CTRL+TAB may need to trigger this as well. (1-C) We can't technically guarantees that multiple nodes in a same hierarchy will be able to fullfill all constraints (e.g. if there's not enough space for everything) so your code would still need to be aware of that. (2) We support 1 but only when there's 1 tab in the node, which would create a weird discontunity when docking another window and hinder docking usage. (3) We support per-window constraint, and instead of applying the contraint in the docking node, we leave the hosting node untouching and make our window fit a larger or smaller space within the hosting node. So e.g. if your constraint specify that the window must be square, and the docking node is not square, the window will still occupy a square space within the docking node, and some space in the docking node will always be empty. (4) We support per-node constraint, meaning it will take more work/maintenance for the users to apply constraints without mistakes if the docking layout is dynamic and persistent. In my opinion I think (3) is the only viable solution for this problem. It's unperfect and definitively won't handle all situations in the way you'd expect. |
Number 3 will be perfect for what I have in mind!! What should I call to set this pre_window-constraint? |
You can't do it, all those solutions would need to be implemented. |
execuse me. had this issue been fixed in the lastest version ? |
I'm interested in something like this, too. For now I've settled with something like: ImGui::PushStyleVar(ImGuiStyleVar_WindowMinSize, ImVec2(250, 250)); But would be interesting to have different minimums for different DockNodes / splits. |
has there been any movement on this? I too would like to set minimum/maximum size for splits. |
I tried doing it manually but didn't got it to work if (AssetsExplorer_window_size.x < cellSize)
{
ImGui::SetNextWindowSize({cellSize, AssetsExplorer_window_size.y});
}
else if (AssetsExplorer_window_size.y < cellSize)
ImGui::SetNextWindowSize({AssetsExplorer_window_size.y, cellSize});
ImGui::Begin("Assets Explorer", NULL); |
@luis605 this topic is literally discussing the fact that this doesn't work when docked. |
Since this issue has been a while... |
@ocornut Hi, when can i set the minimum size of a docked window? When will such a fundamental feature become available? |
Version: 1.74
Branch: docking
Back-ends: imgui_impl_sdl.cpp + imgui_impl_opengl3.cpp
Operating System: Windows 10 pro
Hi, I'm making a game engine and some days ago I downloaded the docking branch. Everythng is perfect and really easy to implement, but I'm having trouble in knowing how to set a max/min size for the windows when they are being docked.
My problem is this gif, is there an option to set a max and min size of a window when docking?
I have tried to use ImGui::SetNextWindowSizeConstraints(), but you still can make the window small.
What should I do? Is there an option to solve this?
Thanks!!
The text was updated successfully, but these errors were encountered: