Re: [Alephmodular-devel] GUI: 0.4 planning

[Woody Z. I. <woo...@sb...>]

I'd tend to think that the cross-platform (SDL) stuff should be the 
"default", with the Mac OS-specific stuff as one special case, rather 
than vice versa as A1 seems to believe.

(Note that A1/SDL works fine on Mac OS X, but since the Carbon has a 
somewhat nicer UI it's the preferred version.)

Anyway, as far as polish, that's clearly what the platform-specific 
stuff is for, and as for reinventing the wheel, well I think Christian 
Bauer and I already did that with the SDL-based dialog widget stuff for 
A1.

So I think we should have cross-platform (shared) routines that do 
things like "set the values of the controls to values from the 
preferences", "change the enabled states of various controls when other 
controls' values change", "extract the values of controls into the 
preferences", etc.  The platform-specific routines then map primitives 
like "enable control" or "set control value" to the platform-specific UI 
code.  Again I'll refer you to dialogs like Setup Network Game in A1 for 
how this might look in practice.  Naturally ideally it would be even 
cleaner, without those occasional #ifdefs cluttering up the 
cross-platform routines...

Hmm I'm maybe still not quite being clear.  I'm thinking of two separate 
things here:

1.  Splitting UI code into shared "logic" routines and 
UI-widget-library-specific primitives
2.  Providing a set of those UI-widget-library-specific hooks for the 
SDL widget system, as a baseline default UI for all platforms, and 
providing a set for Carbon as a specialized, nicer Mac OS-specific UI 
for Mac users

Likewise, for file handling, the baseline should be some sort of 
single-fork-based scheme, and there can be a Mac OS specialization that 
lets some things live in resources for compatibility with existing files.

As for files again though, right there should be specific objects that 
are responsible for loading data?  So that additional loaders can be 
added later for other file formats.  This can be a layer separate from 
the basic routines that deal with physical data containers 
(single-forked files, Mac OS files, in-memory data, etc.).  There should 
be a nice "data container" abstraction to make all of these look alike 
to the loaders.

As for where the physical containers are located, well that's a 
platform-specific detail.  :)  For example, Windows probably wants user 
data stored somewhere and static (game) data stored somewhere; Linux 
would probably put each one in a different spot, as would Mac OS X, as 
would Mac OS 9.  So, maybe there should be a "Platform" object that is 
able to provide information like "where does user data go?" and "where 
should I look for game data" and "what default user name should I use?" 
and "what UI system should I use?".

You know, so there's an abstract superclass (basically a Java 
"interface" or an Objective-C "protocol") Platform that defines the 
names of the methods for the above etc.  Then the Mac OS version is 
built with a MacOSPlatform subclass that provides the MacOS-specific 
implementations (maybe some of which change their behavior at runtime 
based on whether it's running 9 or 10.1 or 10.2 etc.); the Windows 
version is built with a WindowsPlatform subclass, etc.

I suppose there's not strictly a need to use the class mechanism for 
this sort of thing; you could just have a header file with the interface 
and link in different implementations on different platforms.  But using 
the explicit class mechanism would allow e.g. two implementations to be 
linked in but only one chosen at runtime.

Object creation should be done by some sort of 'factory' mechanism, so 
that e.g. one type of object can substitute for another easily with the 
factory deciding which to use, instead of potentially having to hunt 
through later for all the 'new's or malloc()s and have the "how to 
allocate object" logic spread all around.  So you'd do something like 
'Factory::GetInstance()->CreateProjectile()' instead of 'new Projectile' 
or '(Projectile*)malloc(sizeof(Projectile))'.  So if you're playing 
MyFancyGame, Factory::GetInstance() returns a MyFancyFactory, which 
returns a MyFancyProjectile instead of a boring old M2 Projectile.  (You 
wouldn't do Factory::CreateProjectile() because then you're always 
getting Factory's implementation.)  Of course, the Factory could be one 
part of a bigger object (like a Game object or something), or it could 
be split up into a few smaller objects (a NetworkObjectsFactory, a 
GameObjectsFactory - and maybe those are part of larger objects - etc. 
etc.).  But anyway, making any kind of standard creation mechanism 
(something greppable) now makes later alterations much easier.

Of course, being able to return a MyFancyProjectile* instead of an 
M2Projectile* may not be too handy if they are just plain old structures.

Woody

On Tuesday, December 24, 2002, at 12:38  PM, Br'fin wrote:

> I must say that the concept of having a Cross-platform API around the 
> currently platform specific dialogs (Preferences, Network prep and 
> finishing) does have its merits. Especially if for whatever reason 
> those elements need to be changed. (General addition of features, or a 
> project wanting to add their own preferences)
>
> I find myself either worrying about the polish or worrying about 
> reinventing the wheel.
>
> Hsm, just had an idea.
>
> How reasonable is it to say for now 'each GUI implements their own UI' 
> with a note to have someone later come back and work on an additional 
> GUI which hits the cross-platform points better?
>
> Alternatively, each GUI implements their own UI and then we all swap to 
> SDL when it feels like it has enough polish.
>
>
> Mmm, thoughts on Cross-platform resources? Most notably text strings in 
> marathon2.resource, pop up menu lists, and dialog texts? I suppose in 
> addition this would include 'Just where would SDL resources go?'