UI

It's funny that only with time and experience you start to understanding how hard UI code is. I remember a lot of situations when UI freeze in meantime of doing something. Whole window is locked and you just prying that its still alive.

First version of my tools were similar: everything happening in one thread which was block when I was doing some longer operation. Because there was not too much to process it was not so painful. With time this changed, amount of data grow. To fix the issue I started adding progress bars to some operations and was happy.

Sadly I was still wrong. This solution is still messy. I block whole UI and just update progress bar when some operations may be processed in background. Recent change of threading taught me beaut of asynchronous operations.

Right now all my communication Engine <-> UI is happening by events which cleaning my design of whole tools. All code where I mix UI with mechanics changing in creation of event and processing of it later. Bellow you can see code creating event:

if (auto* event = m_appCtx->createEventT<CEditorEventGetLevelProperties>())
{
    event->setLevelSessionID(m_levelID);
    event->setUserData((size_t)a_properties);
    m_appCtx->submitEvent(event, funcEventCallback()
                                 .connect(this, &QWrPropertiesEngine::onRequestTreeEvent));
}

Later I just need to process returned callback:

void QWrPropertiesEngine::onRequestTreeEvent( CEditorEvent* a_event )
{
    if (EErrors::isFailed(a_event->getErrorCode()))
    {
        return;
    }

    QPropertiesWidget* properties = (QPropertiesWidget*)a_event->getUserData();

    Q_ASSERT(properties);

    auto* event = WR_RTTI_CAST_PTR(IEditorEventProperties, a_event);

    Q_ASSERT(event);

    properties->clear();
    ...
}

I like this approach so much that I will probably switch in game UI on the same basics. How it will go we will see but for now I fell that this is good decision.

Greg