search

ocornut / imgui

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

Make SeparatorText[Ex] aware ImGui::SetNextItemWidth #7255

Open w0utert opened 7 months ago

w0utert commented 7 months ago

Version/Branch of Dear ImGui:

Version 1.90, Branch: docking-layout (imgui-node-editor)

Back-ends:

imgui_impl_vulkan.cpp + imgui_impl_sdl.cpp

Compiler, OS:

MacOS & Linux

Full config/build information:

No response

Details:

I am wondering whether it would be possible to make SeparatorText aware of the item width set by ImGui::SetNextItemWidth or ImGui::PushItemWidth

Right now, the separators always use the window max x coordinate to determine their width, which is problematic if you want to use them inside a imgui-node-editor node, see reported issue https://github.com/thedmd/imgui-node-editor/issues/214

In many cases the width of the content area in such a node is fixed or can be calculated upfront, and the calculated width can be used to size the controls inside the node. This works fine for most things, but SeparatorText does not listen to the item width set using SetNextItemWidth or PushItemWidth. I don't really see a reason why, it seems like a useful thing to be able to restrict the size of separators.

Is there a reason why this would be a bad idea? I can probably implement the changes myself and create a PR, but if it's already known it will not be considered for merging it would be wasted effort because I don't want to keep a customised ImGui branch for my application.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

No response

ocornut commented 7 months ago

I would prefer to move forward with APIs to alter window’s WorkRect, maybe the node editor can alter WorkRect.Max.x and ContentsRect.Max.x ?

w0utert commented 7 months ago

I would prefer to move forward with APIs to alter window’s WorkRect, maybe the node editor can alter WorkRect.Max.x and ContentsRect.Max.x ?

I probably sort of agree with that, from my perspective the ideal solution would be if I could set the node width explicitly and everything is sized accordingly.

I think though (but I may be incorrect) that the problem is that imgui-node-editor cannot know the width of the node until it is fully defined, so it has no chance to set WorkArea (and also there is no official API for it I think)? So far I've just refrained from using any widgets that use the window size (e.g. also collapsing headers), but these things would be super useful to have, so I'm looking for alternative ways.

ocornut commented 7 months ago

from my perspective the ideal solution would be if I could set the node width explicitly and everything is sized accordingly.

That would be a thing to investigate on the imgui-node-editor side.

I think though (but I may be incorrect) that the problem is that imgui-node-editor cannot know the width of the node until it is fully defined, so it has no chance to set WorkArea (and also there is no official API for it I think)?

I'm not sure how it work but I would presume it use temporal coherency or two passes to record width, and it is possible for it to write to WorkArea.Max.x for a given frame.

So far I've just refrained from using any widgets that use the window size (e.g. also collapsing headers)

Normally CollapsingHeader() and Separator() query the current width but only declare the width they need (which in the case of Separator is zero) so that size measurement can may performed.

w0utert commented 7 months ago

@ocornut thanks, I will ask @thedmd for feedback if what you are suggesting is feasible, it feels like it would be a really useful feature to be able to use this type of control (also e.g. collapsing headers) inside imgui-node-editor nodes