Re: [Alephmodular-devel] GUI thoughts

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

Expanding on the GUI stuff I mentioned before. I think it might be 
better to have two class trees.

One would be CGUIBasic. And the other would be AlephGUI.

CGUIBasic would be responsible for low level GUI things and their 
platform specific implementations. For instance, this is the class that 
would handle alerts and simple OK/Cancel dialogs. It would also 
initialize the platform specific GUI managers that aren't covered by 
CDisplay. (As such it should be dependent on CDisplay)

AlephGUI would be akin to the GUI class I mentioned previously. This 
would be Application aware, and so it's probably better to have it in 
its own class as a result.

On Jan 8, 2004, at 10:35 AM, Br'fin wrote:

> 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.