Re: [Alephmodular-devel] GUI thoughts

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

Some further thoughts on this matter. A different approach perhaps.

I came to the realization that the dependency of certain sets of 
classes should be a little more straightforward. For instance, it is 
typical in older Mac programs to do all of the Mac initialization in 
one place (All of the calls to init certain APIs, setting up more 
master pointers for handles and so forth.)

And to some extent, AM had been leaning away from even something like 
that. So I figured I was missing something there. After some mulling 
when I was trying to get to sleep, I had thoughts of an arrangement 
like I was thinking of for the GUI hierarchies. CApplicationServices 
would contain all the low level stuff common to applications, such as 
platform specific initialization. At which point, the other class 
hierarchies could then refer to it in their own initialization with 
CApplicationServices::get_instance(); to ensure that the right 
dependencies occur. This would probably be important to some of the 
existing classes, such as the CDisplay and CFile ones.

CApplicationServices could also manage everything CGUIBasic might have 
done anyways.

At a higher level, you have CApplication as the underlying classes for 
AlephApplication. (AlephApplication would probably take the place of 
the existing AlephModular class and I think is better named.) 
AlephApplication would then be the owner of the event loops, and the 
top level modes the game enters (intro screens, main menu, chapter 
screens, playing) However, AlephApplication would then need to rely on 
CApplicationServices and the other classes for anything platform 
specific. It might be a bit much to have something like 
CApplication::instance = new AlephApplication_Carbon(). It certainly 
seems inappropriate to me.

At the very least, having a nice generic class for dependancy purposes 
also helps cleanup a niggling issue with CFiles. Namely the existing 
CFile has to panic and issue a call to an application specific class 
(AlephModular) to report errors that occur when performing Safe Save 
File Swapping during the closing of a file stream when it must panic.

The GUI of things like the preferences dialog and the other setup 
dialogs is probably still interesting and unique enough to be put into 
its own framework of AlephGUI classes.

-Jeremy Parsons

On Mar 14, 2004, at 8:09 AM, Br'fin wrote:

> 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.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>