> I'm considering moving the DrawMap and DrawMiniMap code from Game into > libgag widgets, which would be a logical start.
Yes. But I would move the drawing only part to a drawer helper class that, at first, can be used from the game directly without the need to port all game gui code to libgag. Then a widget which uses this drawer will be done and used in the new map editor which will be based on libgag widgets. Once this is done and tested, we might change the game gui to libgag. The drawer will have some state such as the viewport and wether the lines, accessibility things, etc.. must be shown. Those state must be easily accessible from outside. > After that, I might seperate out GamePanel, which draw the transparent > background for the side and top panels. The DrawMiniMap would fit > snugly into this, hopefully. Please note that there is already a GUIMapPreview widget which might be a good base for the minimap. > Then I would make a set of graphic buttons for what goes under the > minimap, and these buttons would swap hide/show other panels, such as > ChooseBuilding, or GameStatistics. Further more, GameStatistics could > be devided into a generic Statistics widget which would be provided a > reference to a vector which would hold the current statistics. > > Buildings and flags could be done using a GraphicalRadioButton type > widget, which is a set of buttons of which only one can be selected at > a time, and this could then be reused in the MapEditor. A normal TextButton can already have graphics. But if you want to make a graphics only button, faire enough. > The "zones" however pose a particular problem in the widget system, > however. I think the only possibility would be three widgets, a > ZoneType, ZoneAddOrRemove, and BrushShapeChooser widgets, which we > could use boost::function to provide callbacks in which we would tie > them together in the main program. Well, we should have a graphical check box widget. Then we should add the possibility to group check box together such as activating one disable others. > As a side note, boost::function makes a very convient way to provide > callback type interface without virtual functions, which would allow > are wigets to be used dynamically. Problem is that in the gui, you typicall want to associate to the callback a method in a certain instance of object (such as MapEdit). The Qt style signal and slot are nice for this. Libgag's actual solution is an old-fashioned one with a general callback and some standardised parameters. It has the advantage of being easy to understand, fast to compile and easy to debug. But it's not very nice. As far as I remember boost has signal/slot mechanism. Just one comment : beware over engineering ;-) > I think it might all be do-able using libgag, although it would take > allot more work than seems nesseccary just to re-write the map editor. Yes. So I strongly suggest not touching the in game gui for now, only putting drawer in a separate class, and only make clean libgag-based map editor. This will also give us experience of potential problem of this method. We can always change the game gui to libgag later. Steph _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
