[Alephmodular-devel] GUI and Input

[Br'fin <br...@ma...>]

I've got a couple different threads winding their way through my mind 
currently. One being walling off the GUI from the base code. And the 
other being separating out main event loop, and input especially, from 
the game specific code.

Now I know I need to actually inspect both issues to form a better 
plan. And I also need to decide on a focus. But I thought I'd lay out 
my thoughts now.


GUI scenario:

	{ setup options for gui element. This has in/out elements }
	GUIOptions{subclass} options(...)

	if(GUI::get_instance().{call appropriate gui element}(options))
	{
		{ do stuff on successful call }
	}

Now a few notes. The GUI *is* Application aware. So we're going to see 
methods like:
	show_marathon_preferences
	show_save_game_dialog
	show_save_replay_dialog
	show_do_you_want_to_quit

They key thing that the GUI class would be doing is putting a hard wall 
between the basic Marathon code and the dialogs. I admit this doesn't 
make it easy to share code between different platforms ways of handling 
dialogs, but this isn't meant to do that. It's not meant to be 
wxwindows or anything. It is simply to isolate where Marathon asks for 
GUI elements and keeps them clear and defined.


The other area of contention is handling the main event loop and input. 
This is tricky, for a number of reasons.
	* Much reliance on a MacOS Classic style WaitNextEvent loop (with 
extensions)
	* VBL Input thread that polls and processes input and stores in replays
	* Unclear view of networking and how they interact with input polling
	* AppleEvent instigated file selections
	* command key equivalents handled through menu code
	* MacOSX Input polling doesn't like the VBL thread at times
		(faulty mouse tracking, sometimes not watching keyboard)
	* New System should be tight, concise, and lightweight

This will probably also require some new threads and some new 
interactions. For instance, trying to push updates and especially 
screen rendering away from the main event thread. (Thus letting event 
processing go fast, with only world and viewport updates taking 
typically longer)

I need to do some more thinking and planning on this, but I believe 
there's going to be a thread added and denoted as 'main input and gui 
thread.' And I guess the GUI is going to have to be aware of it, so it 
can halt a thread, ask the main input thread to process the gui, and 
then pass the results back to the appropriate thread.

Mmm, I definitely need to sit down and do some more planning/thinking 
here. I have trouble wrapping my head around threads at times :)

-Jeremy Parsons