Being able to push and pop ImGuiTreeNodeFlags to the shared stack

[apilatosba]

Version/Branch of Dear ImGui:

Version 1.91.9b, Branch: docking

Back-ends:

custom backend (c# vulkan glfw) (https://gist.github.com/apilatosba/5aafcbeff36dd9a6c8900f4d00bd942b)

Compiler, OS:

linux, gcc

Full config/build information:

Dear ImGui 1.91.9b (19191)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=201103
define: IMGUI_DISABLE_OBSOLETE_FUNCTIONS
define: __linux__
define: __GNUC__=13
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: NULL
io.BackendRendererName: NULL
io.ConfigFlags: 0x00000083
 NavEnableKeyboard
 NavEnableGamepad
 DockingEnable
io.ConfigViewportsNoDecoration
io.ConfigNavCaptureKeyboard
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x0000000A
 HasMouseCursors
 RendererHasVtxOffset
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,64
io.DisplaySize: 1179.00,693.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00

Details:

My Feature Request:

good morning! i would like to have a feature where i can push a treenodeflag to the stack and this flag will be applied to every tree node that comes after it until i pop the flag from the stack. for example something like this (pseudocode):

ImguiPushTreeNodeFlag(ImGuiTreeNodeFlags.DefaultOpen);
if (ImguiTreeNodeEx("t1")) {
   if (ImguiTreeNodeEx("t2")) {
      ImguiTreePop();
   }
  ImguiTreePop();
}
ImguiPopTreeNodeFlag();

and tree nodes will be open by default for example.

Why i want to do this:

Consider this scenario. i have a recursive function that renders an imgui window, lets name it DoInspector(). DoInspector() function renders components. What i want to do is something like this:

ImguiPushTreeNodeFlag(ImGuiTreeNodeFlags.DefaultOpen);
DoInspector();
ImguiPopTreeNodeFlag();

so i dont need to provide the "shared flags" to each ImguiTreeNodeEx() call in DoInspector()

Workaround

I can just provide the treenodeflag to each ImguiTreeNodeEx() function thats called in DoInspector().

A scenario where workaround doesnt work

Imagine that DoInspector() function allows some sort of custom component rendering. it does so by accepting function pointers. And those cunstom component renderer functions may even come from a different dll (imagine that DoInspector() is in engine dll and custom component renderers may come from game dll. game developer creates a component and also a custom renderer for it for example). In this scenario the workaround above doesnt work because in this case i am not even the one writing the code anymore so i cant provide the necessary flags to the indivudual ImguiTreeNodeEx() calls.

---

basically what i want is ImguiPushItemFlag(), ImguiPopItemFlag() but for tree nodes.

i am not asking for it but also this can be extended and applied to other imgui items like buttons, combos, texts, tables.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

there is no issue but just a request :)

[apilatosba]

oops. i forgot to say but i use this c# bindings: Hexa.NET.ImGui version 2.2.7

[ocornut]

Hello,

What you call the “workaround” appears to me like it a correct, reasonable and mostly,
the most flexible solution.

There is a possibility we’ll want to support better programmatic opening/folding of nodes (#7553 #1131) but that will go a through a more specific API as closing needs to proceed deep-most.

Shared stacks come with varying side effects and each is carefully designed based on certain use cases. In the case of recursive functions it doesn’t seem a great idea, what if eg you add popups in your leaf helpers? What is the tree is non-finite and has loops? Also varying tree node flags have effect on expected behaviors for caller.

From my pov if you already have a solution available (what you call the “workaround” but which seems good to me) then so you should go for it instead.

(PS: In your scenario of shared plugin I am afraid it’d be best to design an hypothetical plugin architecture according to the fact that ImGui does not provide ABI compatibility so plugins would need to be compiled using the same version of dear ImGui.)