On Mon, 2004-08-02 at 20:36, Matze Braun wrote:
> This mail is mainly for James...:
>
> As I have nothing to do in tuxkart at the moment, I'd like to work on the
> GUI. I just wanted to ask what you are working on right now, so that
> we can somehow work together without too much interference.
>
> Will we support some sort of config file for the GUI descriptions? I could
> create a file format and write a parser for it.
>
> I could also simply start desigining some of the special widgets which
> we'll need for selecting cars and tracks, or simply start designing some
> of the screens outlined in the wiki.
>
> Could you gimme a brief report on the current status of the UI?
>
> Greetings,
> Matze
I started totally rewriting it such that it was all object based and I
had a Widget class from which you derived all GUI stuff, like in ClanLib
or indeed most OO window stuff as far as I can tell. However, I then
decided that this total rewirte probably wasn't worth it, and so my new
design is very similar to the original Neverball (which is pure C).
If you think it would be worth rewriting it all in an OO way, we could
do that, what do you think?
But anyway, the way I'm doing it now adds three globals:
1. widgetSet* of class widget, which is what was the GUI code in
Neverball, except put in a class such that the init function is now a
constructor and the deinit function is now a destructor. In CVS this is
still called gui* of class GUI, but it's not any more.
2. gui* of class BaseGUI.
3. An enumerated variable that can have a value of (I'm making these
names up on the fly, I've not actually done this yet, so the names will
probably change) GUI_CURRENT, GUI_MAINMENU, GUI_SETKEYS,
GUI_CHOOSETRACK, etc.
On this note, should I actually use an enum, or just do it via an int
and lots of #defines as does the rest of the game?
The way the Neverball GUI code works, you tell widgetSet to create a
widget, and it gives you back an id. You then call WidgetSet functions
when you want to do something with your widgets, giving the id of which
widget you are referring to.
BaseGUI is just a handle class - everything in it is purely virtual.
The idea is each possible menu screen/state derives from BaseGUI, and it
will store a collection of relevant IDs, and have all the code specific
to any particular widgets.
When you want to go to a new stage (i.e. to a different menu screen, or
indeed into the race), you change the value of the global enum to
something other than GUI_CURRENT, and then somewhere in the main loop
gui will be deleted. This calls the destructor of whatever GUI class is
there currently. Each destructor will delete any widgets it has created.
You then say gui = MyGUIClass, and the constructor of MyGUIClass will
set up all the widgets for that screen.
There's still a few minor issues meaning it doesn't compile right now,
and I have to go to bed soon so I can get up at 5 tommorrow morning to
go to work. However, if you give me another day (as in, 24 hours), I
should have it committed.
At that point the basic structure would all be there, and we could then
work on seperate menu screens - e.g., I could do the main menu screen
and the in-race stuff for now, whilst you could do some other menu
screens (e.g. choose character, choose track, configure keys, whatever).
Obviously it will require some coordination such that our menus
interlink correctly.
Unless you want to rewrite it all to be properly OO...
James
|
