It is common practice that text editors save changed content upon losing focus. There is no need to press Enter, Tab, “Save”, or otherwise commit a change manually. Just selecting another item in a ListBox should save the changed text to the currently selected item.
However, when I edit some text and then select the next item in a list, the changed text is lost (or saved to the next item) because the “lost focus” notification (to the TextEditor) is sent asynchronously, while the selection change (to the ListModel) is sent synchronously. Thus the editor loses focus only after the selection has moved to the next item.
This mix of synchronous / asynchronous communication messes up the sequence of events. It’s impossible to properly process a transition between selection states when notifications don’t arrive in chronological order.
For now, I fixed this with a patch that sends onFocusLost in textEditorFocusLost() to the TextEditor synchronously. That’s not a permanent solution of course. I guess this was originally made asynchronous for a reason.
It’s a general architectural decision whether focus/selection/state changes are dispatched asynchronously or not. They must be handled the same way across the entire system in order to maintain chronological order. Asynchronous change propagation is generally more robust, especially when user actions can trigger a rebuild of the UI (e.g. the button you just clicked disappears).
But this requires to get rid of all synchronous notifications(!) I guess that’s a major refactoring we won’t see anytime soon?
If so, would it make sense to at least send onFocusLost synchronously?