[Freeciv-Dev] Re: RFC: Unifying mapview parameters

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

At 11:11 PM 02/01/15 -0500, Jason Short wrote:
>Each different GUI has its own parameters for the mapview, but they are 
>almost identical.
>
>GTK:
>   map_view_x0, map_view_y0 => window origin (in mapview.h)
>   map_canvas_store_twidth, map_canvas_store_theight =>
>     window width and height in tiles (in gui_main.h)
>   mapview window pixel dimensions are determined on-demand
>
>XAW:
>   (same as GTK)
>
>WIN32:
>   map_view_x, map_view_y => window origin
>   map_win_width, map_win_height: window pixel dimensions
>   mapview window tile dimensions are determined on-demand (I think)
>
>MUI:
>   map_view_x0, map_view_y0 => window origin
>   everything else is determined on-demand
>
>I propose that these be unified into one common set of values in 
>mapview_common.[ch].  This will allow further unification of the mapview 
>code (including center_tile_mapcanvas, get_map_xy, get_canvas_xy, 
>get_center_tile_mapcanvas, tile_visible_and_not_on_border_mapcanvas, 
>tile_visible_mapcanvas, show_city_descriptions, and 
>update_map_canvas_visible for starters, update_map_canvas and others 
>with a little more work), make cross-GUI programming a lot easier (no 
>more need for everyone to think about these differences :-), and make 
>the code (very insigificantly) faster.
>
>I also propose that they take the form of a struct:
>
>   struct mapview_window {
>     int origin_x, origin_y;
>     int pixel_width, pixel_height;
>     int tile_width, tile_height;
>   } mapview;
>
>although this could just as easily be 6 separate values.

How about x0 and y0 for the values so the code references mapview.x0
as opposed to map_view_x0.

Also pixel -> canvas, it also is the current code pseudo-standard
and the confusion of having both pixel and canvas refer to the same
thing in different contexts should be done away with. You can cleanout
the pixel flavour over time (it is slighlty more restrictive and thus
less desirable).

tile_width, tile_height are too ambiguous or generic. Do they refer to 
NORMAL_TILE_WIDTH, NORMAL_TILE_HEIGHT, or something else like 
canvas_twidth, canvas_theight, that is at least a clue when they are
sitting next to canvas_width and canvas_height. The t- flavours are
also a pseudo standard that might one day be documented.

But it would actually be best to make these the "normal" flavour as this
is then a complete and self-contained struct with the ambiguous context
computable from this, and not all that commonly used, so doesn't really
require caching.

Also add is_isometric to this in some way to complete the "view" 
description and consolidate *all* the relevant globals.

But don't change things any more than necessary :-)

>There are really 5 parts to this conversion process:
>   - Introduce the struct into mapview_common.[ch]
>   - Change GUI-specific code for each GUI to use the new structure.
>I can provide patches for each of these steps, but the GUI authors 
>should verify and apply them (at least for MUI and WIN32, which I cannot 
>test).
>
>jason

Concept and general approach is worthwhile. Go for it ...

Cheers,
RossW
=====