Option to bring absolutely positioned) button to front?

[giogina]

Is your feature request related to a problem? Please describe.
I have this button with an absolute position set. No matter when I create it - even as the very first or last thing in my main window - it ends up behind another item (if it's relevant - a plot within a child window within a table), so that it's not clickable.

Describe the solution you'd like
I would like this button to hover above all other items and be clickable. Either through a z ordering option, or maybe items with absolute position should by default be above other items.

Describe alternatives you've considered
Tried all orders of item creation, none worked. Layers are for draw items only, right?

[v-ein]

Unfortunately the immediate GUI paradigm doesn't work well with Z ordering.

Here's an explanation on item overlapping that I gave some time ago on Discord. It might explain why you're having troubles with the abs-positioned button. We can try to make it work for you if you attach a piece of code and a screenshot of what you're getting and what you want to get.

(the text below is a copy-paste from a Discord thread)

---

Personally I don't see any problems with that. You can overlap most widgets in DPG, provided that you understand how ImGui works... That is,

1. For regular widgets, the widget being rendered first swallows events that it can handle. E.g. if you overlap two buttons, the first to render will handle the clicks and hovers.

2. The widgets are rendered one atop another, that is, for two buttons, the one that visually stays at top is the second one, not the first. That's why you normally don't want to overlap buttons: the first gets all events, the second is most visible (remember the background is often translucent so we still see the first button), and the overall result is weird. But for some other widgets it works pretty well.

3. Windows isolate event handling so if you put a window on top of something, even with transparent background, the window (or its children) will get the events. Applies to child_window, too.

4. Things might become weird in tables because tables are rendered in a non-trivial way, but most of the time it all goes as usual.

To overlap widgets, use pos=(x, y), OR if you're brave enough you can try to use a table with no_clip=True.

[giogina]

Thank you! Just leaving the screenshot here for now, as I won't have time to extract the relevant code sections until Monday. It's this small caret button on the top left corner (right under the import data tab), meant to expand a panel back out, so not taking up extra space is kinda the whole point of it (although currently I'm circumventing the problem by using a spacer next to the plot normally while the button is there).

Btw, the plot functionality is amazing, never had a plot this interactive!

[v-ein]

Try to put the caret button into its own child_window and see if it works for you. If the plot overlaps it, try to create the button (and the child window) after the plot, not before.