Skip to content
This repository was archived by the owner on Oct 29, 2023. It is now read-only.

Internal structure

Simon edited this page Jan 7, 2021 · 1 revision

Storing controls

Controls are stored in fui_main in a hash map with the control's name being the key and a std::unique_ptr<control> being the value. This allows the retrieval of controls from their name. The reason they're stored in std::unique_ptrs as opposed to std::shared_ptrs despite being shared with for example container controls is that the controls live and die with the fui_main object (ui). As such there's no need to for the controls to be owned by more classes than the ui.

Despite the controls being dynamically allocated, providing the pointer to the control to a smart pointer will still allow it to manage the memory and clean it up properly.

Events and drawing

The controls are structured as a tree, with the root node being the displayed control in fui_main and any subsequent branches being the various controls contained by the displayed control, should it have any. These parent nodes are container controls and each one has a selected node or control to which user input is redirected.

When the user presses a key, the event is typically passed down the branches of selected nodes until it reaches an end node. There are some exceptions to this, for example the up-down arrow keys which are processed by pages directly and the left-right arrow keys which are processed by other container controls directly. If a user input causes some change in a control or how the control should be drawn, the control is marked as invalidated, meaning the currently rendered control body is outdated. This invalidation is passed upward, such that each parent node up to the root node is invalidated after which the ui is redrawn, causing the invalidated controls to update their bodies.

This system has two benefits:

  1. the ui is redrawn only when it needs to be
  2. the control bodies can be cached and updated only when neccessary
Clone this wiki locally