Re: [glob2-devel] Re: I am taking upon the task as to redesign the map editor

[Stéphane Magnenat]

Hi,

> Weeks have gone by...
> The mainling list remains silent...

Well, as usual, we have to work on other stuff to get a living. But rejoice, 
tomorow evening, Nuage and me should work more on unit allocation rewrite

> I'm sorry for criticizing your code, nct and nuage.

That's ok :-)

> Back to the map editor:
>
> I'm trying to get the map editor to use the same kind of panelling as
> in the main gui, and I've run into one main fault. The map editor is
> seperate to GameGUI, and its GameGUI that does the drawing and
> containing of the Game, however, its Game that draws the main screen.
> In a similair effect, MapEditor also contains and manages a Game,
> however, I need to tap into GameGUI's drawing code to be able to share
> the panelling (without the ubliquous copy and paste).
>
> What I'm thinking is that we take seperate GameGUI and MapEditor from
> Game, and instead, have all three classes managed by Engine. So Engine
> will contain a Game, and either a MapEditor or GameGUI depending on
> the circumstances. In this manner, MapEditor and GameGUI are under
> Game, instead of the converse, and handle only user-interface related
> things. This would free up MapEditor to use GameGUI for whatever
> reason, or even better, a third class could be made (or a set of
> widgets based on libgag, for future for-seeable), which itself would
> only do drawing, and both GameGUI and MapEditor share usage of this
> "Drawing" class. Although the latter would take longer, it would be
> more permament.
>
> Do you feel this is acomplishable? If your available, we can discuss it on
> IRC.

Well, we fully agree with this criticism. In fact, we have already discussed 
this and we indeed think that using a third "Drawer" object is the clean way 
to go.I don't think it should go into the engine, but rather be just another 
class. Now the question would be, should it be a widget. Theoretically it 
would be cleaner, but would propagate the refactoring deep into the in game 
GUI (in fact, invalidate the whole actual in game GUI). On the long term it 
would be nice, but trust me, that's a big things even if it doesn't look 
like, because there is dozens of small behaviour not easy to implement in a 
generic way but critical for the smooth in game user interaction. What I 
would suggest for now is taking the drawing code out of GameGUI object, put 
it in a separate Drawer object, call this Drawer from GameGUI in the game and 
make a widget that embedded this Drawer for MapEdit.

Steph

-- 
http://nct.ysagoon.com