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.
We found that user specified ids wasn't a big deal. We made the ids hierarchical, so that a button "ok" inside a panel "confirm" would have its id computed as something like "confirm/ok". In addition to string constants for ids, we also allowed integers as ids to make it easy to put controls inside of loops. For containers, we used a pattern like BeginPanel("confirm") ... EndPanel("confirm"), so having the explicit ids also made it easy to check that we had matching pairs. There's a little bit of overhead for resolving the ids, but we never found it to be a significant concern.