ocornut / imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
MIT License
60.49k stars 10.21k forks source link

Setting max/min size of windows while docking? #2849

Open OriolCS2 opened 5 years ago

OriolCS2 commented 5 years ago

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? problem

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!!

ocornut commented 5 years ago

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.

OriolCS2 commented 4 years ago

Number 3 will be perfect for what I have in mind!! What should I call to set this pre_window-constraint?

ocornut commented 4 years ago

You can't do it, all those solutions would need to be implemented. Once implemented, solution number 3 would naturally work with the existing SetNextWindowSizeConstraints() API.

CatDroid commented 4 years ago

execuse me. had this issue been fixed in the lastest version ? it also want to limit the width size of right-hand sub-window in whole window

franciscod commented 4 years ago

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.

P-Squiddy commented 2 years ago

has there been any movement on this? I too would like to set minimum/maximum size for splits.

luis605 commented 1 year ago

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);
ocornut commented 1 year ago

@luis605 this topic is literally discussing the fact that this doesn't work when docked.

jay3d commented 1 year ago

Since this issue has been a while... The solution is actually there, you just need to make users customize it. i.e. you already have some kind of a docking slice constraints when you resize the docking slice to a minimum just to keep the docked window control buttons visible: hide title(useless IMO should be replaced with something like a collapse?) and close. This is a very critical piece of a feature that should be there at the beginning. Without this, most of the docking branch is unusable, because users NEED to set constraints in many cases where the content (or a custom drawn content) is very sensitive to small sizes and want to prevent users from doing so to not cause unpredictable crashes or unnecessary complicated code.

pfhgil commented 2 months ago

@ocornut Hi, when can i set the minimum size of a docked window? When will such a fundamental feature become available?