Identifying controls in an IMGUI

identifying-controls-in-an-imgui.md

Identifying controls in an IMGUI

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:

1. 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.

2. 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 with PushId(), 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.

3. 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.

4. 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.

5. 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.

6. 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).

7. 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.

Someone suggested hashing the item rect's too -- which is pretty good since gui items typically don't coincide or move around. Yet, there might be special situations when they do (dragging a graph node perfectly on top of another graph node) that needs to be handled.

Late to the party, but I've found that using a hash of the control's position and window/panel as the control's id like @niklas-ourmachinery mentioned works pretty well. I've never encountered a situation when I wanted a control to move while I was interacting with it. The only exception is dragging, which still works since the UI itself is manipulating the control's position and can thus re-assign the id.

The only aspect I haven't solved yet is dragging objects within the same panel/window to the same position. Since this hasn't been a big problem in my main project, I've been able to ignore it for the time being, but it did come up when I was trying to drag objects on a grid for a quick side project. My only (untested) idea was to combine this with method #3 for drag controls only, since I couldn't think of a scenario when I'd want to modify local x/y variables with a drag-able control.

As a caveat, my UI library is still relatively young, so I may not have encountered the wrong situations for this kind of design. However, I can't imagine a situation (again, other than dragging) where a control is moving while being hot that still provides a good user experience.