[Freeciv-Dev] Re: to wrap or not to wrap?

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 04:13 AM 01/10/15 -0400, Jason Dorje Short wrote:
>Raimar Falke wrote:
[...]
>> 
>> Ok. But this wrapping isn't a map wrapping but a GUI wrapping.
>
>It is a map wrapping; it's just that only the GUI needs it (all the rest
>of the code behaves in a sane manner and doesn't need to).

Good boys, there *is* hope yet :-).

[...]
>> Jason can you point out any problems which the author of a cleanup
>> patch may encounter?
>
>I'm willing to make many of the changes; in fact in the past I've
>scraped together a few demo patches that do this sort of thing.  There
>are several problems that I anticipate:
>
>1.  Doing it in "small steps" is difficult or impossible; since most of
>the functions are closely tied together [1] we'll either need to convert
>large groups of functions simultaneously or separate code out into "new"
>and "old" versions of the same function.  The second is really poor, so
>we'll probably end up with some lengthy patches.  If we choose to go
>this way you must be prepared for this.
>
>2.  A fair amount of code is duplicated in different GUI's.  This means
>extra work is required to fix all of them (often they're not *quite*
>identical), and extra work is required by people to test them on
>different platforms.  The "correct" solution in many cases will be to
>move code into common client functions, but this has the same problems
>as above and is even more work (though with very large payoffs).
>
>3.  Fixing the isometric view will be really ****ing hard.  Those
>manipulations make my head hurt.
>
>4.  Making sure the client doesn't draw a tile more than once will
>require some additional work.  I have several ideas how this may be
>accomplished; it should be fairly unintrusive but again it'll have to be
>verified for all gui's.  Once this is done it should be easy enough to
>explore with showing multiple tiles (as a compile-time, run-time,
>tileset, etc. option).
>
>Really, I don't think any of these problems are all that hard.  The
>problem is they're multiplicative - we'll have to convert ALL functions
>for ALL gui's INCLUDING isometric, AND make sure tiles aren't drawn more
>than once.
>
>For now I recommend we proceed with our small-step methods until we
>reach a point where they no longer work.
[...]

As a suggestion, start a new client hierarchy. Initially you can populate
it with just enough of the current GTK client to compile and get working.

Make your changes within this development tree. If you need to update
core code, look really carefully to see if it is core code and if not
then move it to the oldGUI and the newGUI at the same time. Then change 
it in the new.

If it is core code, write to a newGUI wrapper interface. Put updated
and renamed core stuff into a special directory and point the wrappers
at this for now. Note wrappers can just be MACRO indirections. Mike
Kaufman is *really* good at this if you need examples from civworld.
He may also have a lot of good ideas about how to organize some parts
that have given him trouble in the past.

Evolve or eviscerate the newGUI stuff until you have something solid
enough to consider propagating to the other clients. Add them to the
newGUI hierarchy as they are attacked and completed.

When you have replaced all that you want from the old client and it is
stable, switch the default build to build the newGUI and drop the old.

Move the updated core functions into the core and repoint the wrappers.
For bugwards compatibility, move the old core functions into a similar
spot in the oldGUI hierarchy, add wrappers there, and let anyone use 
the old GUI that still wants to.

>jason

Cheers,
RossW
=====