Collection of the random thoughts about the platform..
Modal dialogs are well known, highly utilized and mostly abused in the GUI world. Most of the time modality of the dialog covers two meanings:
To clarify the things out, need to mention what mode means a state, and thus its a statefull dialogs or in other words dialogs preserving a state as opposing to the the stateless dialogs which operates in parallel.
The former aspect of the modal dialogs is quite useful in many usage cases (altough I bet there are many usability researchers who frown at the sight of the dialog popping out of nowhere and basically forcing user to do something). However the latter aspect can be seen as the implementation artifact. While its simplifies programming approach, its also may cause major interferance with the other application functions which supposed to work at the time when dialog is displayed. It might be viable in the purely GUI applications (or otherwise such application can offload background tasks to the worker thread without a hassle) but in case of the real time games where many things executed sequentially in the single game loop it could create big big problem.
The problem arise from the common (or should I say “windows” inspired?) implementation of the blocking modal dialog boxes. Although the implementation is pretty straightforward and easy to comperhand, it has several inheritent flaws which make it undesirable especially in the game gui.
MS Windows GUI (as well as most of the MS GUI Libraries) implements modal dialogs by nested dispatcher loop, which effectively routes messages to the application’s message loop and at the same time blocks execution until the dialog is dismissed. Nesting message loop basically makes a nasty recursion in the execution path, something like in this scheme:
| Level | Routine |
|---|---|
| 1 | App::Main |
| 2 | App::RunLoop |
| 3 | OS:MessageDispatch |
| 4 | App::MessageHandler |
| 5 | App::SpecificMessageHandler |
| 6 | OS::ExecuteModalDialog |
| 7 | OS::MessageLoop |
| 8 | OS::MessageDispatch |
| 9 | App::MessageHandler |
While game (PH in our case) avoids recursion by decoupling OS message processing and its own message loop, it still requires calling OS message dispatching cycle “from within”. Infortunately this approach is discouraged / prohibited by design of the Symbian GUI libraries.
Thats the mostly straighforward conversion of the current approach. However there are many tricky places in the way how Symbian asynchronous events are scheduled and executed (comparing to the windows message handing) and actually platform documentation strongly recommends against using nested loops.
However, looks like Symbian port of the SDL works that way. Didn’t understand it well, actually. In rough outline it looks like it starts main thread with the single shot async callback and then periodically activates nested ActiveScheduler for system message dispatch. The PumpEvents procedure looks like that:
Its quite clear what modal dialogs could be emulated by decomposing execution flow into two states: in dialog and outside of dialog i.e. instead of calling “execute modal” and blocking in the call we can create dialog widget, set some global state flag and bail out. As soon as the execution path enter new game (or GUI) cycle it will serve dialog’s logic instead of ours. Then as the dialog interaction finishes, it sets that global flag to the new, destination state, effectively redirecting execution to our new entry point.
Its easy to see what, although logically correct this solution is foreign with respect to the c++ programming - having no any effecitve ways for FSM decomposition it dooms programming to splitting otherwise logicically continious program flow into separate parts (which also should carefuly manage the shared state)
<need an example>
Clean, although mostly unsupported in C++ environment method.
Sets “modal dialog flag”, yields a thread on “executeModal”. Global management thread will check a flag and execute dialog code (not allowing to invoke caller thread) until it exist.
Dialog executes in non-blocking fashion. On exit it enqueues “async callback” with its result to the message queue so its served as soon as we come back to the message loop.
Similar to the green threads but even more unnatural to the C++. However if we move to the scripting game core it might be easility enrolled on top of Lua or Squirel language.
Dialog starts separate thread, main thread free to choose: block in waiting for dialog thread or continue exection and block later.
If we thread dialog result as Future (see multithreading ideoms).. it brings out back recursively to the same problem (in case if we access future within same cycle)