StateMachine

[TheRealKaup]

Calling Widget::Deselect() twice by accident (a very probable mistake) overwrites ChildWidget memory unexpectedly, effectively losing track of selected child Widgets.

Current Widget::Deselect definition:

void KTech::Widget::Deselect()
{
	m_selected = false;
	m_callbacksGroup->Disable();
	for (ChildWidget& childWidget : m_childWidgets)
	{
		childWidget.oldSelected = engine.memory.widgets[childWidget.widget]->m_selected;
		engine.memory.widgets[childWidget.widget]->Deselect();
	}
	OnDeselect();
}

If the child is selected, the first call sets childWidget.oldSelected to true, then the second call sets it to false, meaning the parent will not select the child when selected next.

Adding:

if (!m_selected)
	return;

At the start of the function could maybe solve the problem but after testing this solution on TextureCreator additional unexpected behavior occurred, so a more sophisticated solution might be needed.

Designing a UI state-machine made of Widgets must be done with so much attention given to how Widgets are defined, at this point it really would better for Widget to come with a complete engine-integrated state-machine system rather than functions that users must adapt to.

---

Alternative System

• Widgets are deselected by default
• One function to deselect currently selected child widget
• Optional linear scrolling between child widgets (given one key to scroll up and another key to scroll down, or, specific keys per widget)
• Selecting a parent selects all its child widgets that should be selected according to the state machine
• Deselecting a parent deselects all its child widgets
• Selecting or deselecting twice does nothing more than doing so once
• Setting up a system doesn't need a particular order of creating widgets and adding them to others, for example, adding a widget to a deselected parent widget automatically deselects the child widget
• Widgets are agnostic on whether their parent has another parent or their child has another child

Revision

Remove the ability of Widgets to have child Widgets, and instead add a StateMachine wrapper:

// Example representing a state-machine similar to the one of TextureCreator:

StateMachine topSectionSM = StateMachine(
	Keys::left, Keys::right, // The keys needed to scroll between the widgets
	true, // Rotate back to the start/end if reached the end/start respectively
	{ // Vector of states
		State(w1.m_id, true), // true = the default selected widget
		State(w2.m_id),
		State(w3.m_id)
	}
);

StateMachine sideSectionSM = StateMachine(
	Keys::up, Keys::down,
	true,
	{
		State(w4.m_id, true),
		State(w5.m_id),
		State(w6.m_id)
	}
);

StateMachine totalSM = StateMachine(
	{
		State(
			// Lack of key here means no rotating to the end
			&topSectionSM, // A `State` can be a `Widget` or sub-`StateMachine`
			Keys::down // Special key to proceed forward (w7 is below topSection)
		),
		State(
			Keys::top,
			w7.m_id, true, // w7 is selected by default
			Keys::left // sideSection is left to w7
		),
		State(
			Keys::right,
			&sideSectionSM
			// Lack of key here means no rotating to the start
		)
	}
)

A wrapper makes so much more sense here than a full integrated system (and especially an incomplete integrated system), as the user can decide to create their own wrapper (a very likely scenario, might do so myself in netset) while not having to comply with any KTech specification.