← Back to context

Comment by flohofwoe

1 day ago

> How does the system know when that can be done?

At the earlist in the first frame the application UI description code doesn't mention an UI item (that means UI items need a persistent id, in Dear ImGui this is a string hash, usually created from the item's label which can have a hidden `##` identifier to make it unique, plus a push/pop-id stack for hierarchical namespacing.

> then the others will lose their state because of this

Once an item is visible, the state must have been provided by the application's UI description code, when the item is invisible, that state becomes irrelevant.

4 comments

flohofwoe

Reply
amelius  1 day ago

> when the item is invisible, that state becomes irrelevant.

What happens when the item moves out of view, e.g. because the user scrolls down?

State should be preserved, because the user might scroll back up.

  • flohofwoe  1 day ago

    Once the item becomes visible, the application's UI code provides the item's state again.

    E.g. pseudocode:

        for (firstVisibleItemIndex .. lastVisibleItemIndex) |itemIndex| {
        ui_list_item(itemIndex, listItemValues[itemIndex]);
    }

    For instance Dear ImGui has the concept of a 'list clipper' which tells the application the currently visible range of a list or table-column and the application only provides the state of the currently visible items to the UI system.

    • amelius  1 day ago

      Ok, but now items 1,000 through 10,000 are deleted from the data container.

      How does the immediate mode system know that the corresponding state can be deleted too?

      Does the system provide tools for that or does the burden lie on my application code?

      1 reply →