Upside-down tree node triangle #6517

New issue

Closed

opened 2023-06-13 12:16:48 +00:00 by wolfpld · 5 comments

wolfpld commented

2023-06-13 12:16:48 +00:00

(Migrated from github.com)

We would like to request an additional flag in ImGuiTreeNodeFlags_, that would change the expanded tree node triangle to be drawn upside-down. As silly as it may sound, this is for an actual feature that we were requested to do.

@squadack please add additional info, if needed.

We would like to request an additional flag in `ImGuiTreeNodeFlags_`, that would change the expanded tree node triangle to be drawn upside-down. As silly as it may sound, this is for an actual feature that we were requested to do. ![image](https://github.com/ocornut/imgui/assets/600573/dfcf4dd2-cf91-41d7-be99-53383662f1f7) @squadack please add additional info, if needed.

ocornut commented

2023-06-19 09:47:53 +00:00

(Migrated from github.com)

A related thought I often had was that some of our vector-defined shapes could use font glyphs (assuming we have dynamic sized fonts, so a bit later), so being able to "remap" shapes into font glyphs could be useful too. Anecdotally, our vector-based Bullet point shape is pretty expensive for what it shows so it would benefit from using font data.

I assume the right generic direction is we add some kind of basic shape enum (ArrowUp, Checkmark, Bullet) which would redirect to code, with intent of adding some form of remapping support, and maybe easier for up to temporary switch ArrowUp and ArrowDown). But what means standardizing parametrization of those shapes: RenderArrow() and RenderArrowPointingAt() have pretty hardcoded parameters and logic and don't render same shape (that's mostly technical debt).

TL;DR; I see this as an opportunity to come up with a wider design and this should be style data rather than per-instance flags data. But I'm not against adding a temporary hack for you in imgui_private.h in the form of e.g. a ImGuiTreeNodeFlags_FlipVerticalArrow with the gentleman agreement we remove it if we have a better solution.

Linking to related #6090 #2431 #2235 I see an occasional desire to do stuff like that. It feels a bit like opening a can of worm to me but I could investigate finding the right trouble-less design. If we had overly specific style settings then there's pressure to maintain that and it may be discarded with later improvements. If we add callbacks for some shapes it maybe means sizes needs to be known and this may impact widgets code. A related thought I often had was that some of our vector-defined shapes could use font glyphs (assuming we have dynamic sized fonts, so a bit later), so being able to "remap" shapes into font glyphs could be useful too. Anecdotally, our vector-based Bullet point shape is pretty expensive for what it shows so it would benefit from using font data. I assume the right generic direction is we add some kind of basic shape enum (ArrowUp, Checkmark, Bullet) which would redirect to code, with intent of adding some form of remapping support, and maybe easier for up to temporary switch ArrowUp and ArrowDown). But what means standardizing parametrization of those shapes: RenderArrow() and RenderArrowPointingAt() have pretty hardcoded parameters and logic and don't render same shape (that's mostly technical debt). TL;DR; I see this as an opportunity to come up with a wider design and this should be style data rather than per-instance flags data. But I'm not against adding a temporary hack for you in imgui_private.h in the form of e.g. a `ImGuiTreeNodeFlags_FlipVerticalArrow` with the gentleman agreement we remove it if we have a better solution.

wolfpld commented

2023-06-19 12:25:23 +00:00

(Migrated from github.com)

I'm not against adding a temporary hack for you in imgui_private.h in the form of e.g. a ImGuiTreeNodeFlags_FlipVerticalArrow with the gentleman agreement we remove it if we have a better solution.

Seems reasonable. Thanks!

> I'm not against adding a temporary hack for you in imgui_private.h in the form of e.g. a ImGuiTreeNodeFlags_FlipVerticalArrow with the gentleman agreement we remove it if we have a better solution. Seems reasonable. Thanks!

ocornut commented

2023-06-19 12:33:33 +00:00

(Migrated from github.com)

Pushed d96bbf0

Pushed d96bbf0

squadack commented

2023-06-20 10:24:53 +00:00

(Migrated from github.com)

Thanks for the fix! Unfortunatelly, your fix works only on framed tree nodes. I have submitted a pull request https://github.com/ocornut/imgui/pull/6538 that adds the same fix for frameless nodes.