In an IMGUI we need a way to identify which control is active
or hot
. For example,
when we press a key, which text box does the text go to.
Possible options:
-
Sequential number (Unity)
Each control drawn gets a sequentially increasing number.
If controls dynamically pop in and out of existence (e.g. animation), the IDs of subsequent controls will change. This will screw up interaction with those controls. Changing the draw order -- for example bringing a graph node "to front" will also mess this up.
Can maybe be fixed with "checkpoints" -- assigning fixed IDs at certain points and then number sequentially from there.
-
Hash of string (Dear Imgui)
Control ID is a hash of the button label. To support buttons with same label, ID can be appended
"OK##ID1"
"OK##ID2"
. Contexts can be added withPushId()
,PopId()
. Only labels that are the same within the same context are a problem."OK##ID1"
s not very elegant. Context will need to be thread-local, which is not super nice. -
Use address of data that control manipulates
I.e.,
bool *
for checkbox.Not all controls have data (push buttons). Can maybe introduce pseudo-pointers for such controls. What if multiple controls use the same data? I.e. multiple property windows that display data for the same object.
-
Preprocessor
__FILE__
and__LINE__
Only works well for UIs generated in code, not so much for data-driven UIs. Needs additional info when controls are created in a loop.
-
Stateless (Nuklear)
Avoid concept of a
hot
controller. Instead just check "is the mouse in this controller's rect?"Doesn't allow for all kinds of interaction. For example, with a slider you must keep the mouse within the slider's rect while dragging it, whereas standard UI behavior is to "lock" the mouse to interacting with the slider once you click it -- even if the mouse goes outside the rect (i.e. below the slider), it will still affect it.
-
Stateless 2
Instead of storing hot control ID, store history of where mouse was pressed. Determine if we are hot by checking if mouse was pressed on us. Longer history can be stored to determine double-clicking, etc.
Elegant in a way, but breaks down if UI elements start to move around (i.e. dragging nodes in a graph).
-
User assigned ID
Works, but cumbersome for user to come up with IDs.
1 or 3 seems most promising, with 7 as a fallback for breaking ties.
EDITED
#2 having id that are non-opaque and externally computable has other benefits, you can compute or derive the ID of "other" elements. Although dear imgui doesn't fully empower right now it it has its uses, eg you can check if the "OK" button is hovered outside the context/code that produced the button, you can explicitly close a node given an id you computed, in the future you could remotely activate a widget
RemoteActivate("AnotherWindow/OK")
,I would like to explore those ideas in future versions, currently a few specific components add piling semi-opaque information on the id stack, but the idea of building unique pathname to identify any widget could yield lots of potential features.
I don't understand the thread-local comment in #2, most ui code and most of those solutions described require a context somehow.
With this system, explicit id manipulator such as "OK##1" are also the exception rather than the norm, so the burden of those fugly construct is quite lightweight.
Being unable to reorder/add/remove elements would be a deal breaker for me: preserving node open/closed state for a list of object (#2 allow to identify with the object pointer). Gamepad/keyboard navigation also requires keeping the "cursor" somewhere somehow. If you were to lose your keyboard position because some ui changed (esp #1) it'd be not good?
Typical authoring tool ui are fairly static vs ui that allows to visualize in-engine data typically less stable.