[Freeciv-Dev] Re: (PR#4004) A canvas_iterate macro for mapview

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

Note, there is a subtle difference between the concept of native core
coordinates and gui_native coordinates that makes native absolutely
general and gui_native inherently ungeneralizable.

Native core coordinates are rigorously defined to lie in a rectangular
grid which is what the loop iterators loop over. All present and future
native coordiantes are *defined* to have this property so are completely
general. Native core coordinates are not designed for display, so this
could make the grid mapping in obscure cases highly non-intuitive, but
this has no impact on their code use.

Gui-native coordinates should have the same sort of rectangular grid
form for the loop iterator to execute. But since one generally wants
gui coordinates to step over the (admittedly rectangular pixel canvas)
in a tile-specific position order for display purposes, and this order
is in general not expressible as a simple rectangular grid, there is
an inherent problem.

For the current standard and isometric cases, one can still find a
pseudo rectangular native form. This will not be true for all future
gui-native cases, though grid plus mask gets you a bit further.

Such distinctions are also important in making sure one does not mix
or confuse core and gui native concepts.

It also makes your iterator goal a lot trickier than the core case was.
You will need to be very careful to define exactly what the iterator
does and does not do, as opposed to a swiss-army knife that novice or
uneducatable programmers are supposed to apply blindly.

Cheers,
RossW
=====

Jason Short wrote:
> rwetmore@xxxxxxxxxxxx wrote:
> 
>>I think that the following shows what should not be in the basic loop
>>macro, rather than what should be. The problem is one of separation of
>>functionality, and not trying to overload something with every special
>>case possibility. GB actually has the right idea below.
> 
> 
>>Thus, if one rephrases the problem in a suitable way, one just has
>>to do a simple GB iteration over the border+viewable tiles in the
>>window asking them to draw themselves possibly with some context
>>mask that tells an individual tile-draw which adjacent positions
>>might be relevant.
> 
> 
> You're right that the iteration should not know anything about the 
> different parts of the tiles - this should be left up to the user.  But 
> this doesn't change my implementation at all, since it doesn't do any of 
> this anyway.
> 
> 
>>The iteration is realtively straightforward and can probably be done
>>in a single way for both the isometric and standard cases using some
>>sort of gui_native coordinates.
> 
> 
> This is what my current implementation does - but it is not pretty. 
> Clarifying the concepts involved (specicially, defining "GUI 
> coordinates" and/or "native GUI coordinates") may help.  But something 
> that required less code would also be good.
> 
> jason