[Freeciv-Dev] Re: (PR#3727) Rectangular selection with right-click-and-drag

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

On Sun, 2003-03-23 at 09:19, a-l@xxxxxxx wrote:
> On Fri, 21 Mar 2003 05:25:43 -0800
> "rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx> wrote:
> 
> > Under the current regime, passing unnormalized map coordinates or
> > working with them is verboten, even if it makes the task impossibly
> > complex.
> 
> Ok. But may I work with an unreal tile? I still need to use one tile
> as anchor, because I want my rectangle bigger than the mapview.

Yes, you can *have* unreal positions - you just can't *do* anything
map-related with them.

So, it's okay if (-5,-5) is the top-left corner of a rectangle that is
(10x10) tiles in size.  But when you try to do anything with this
rectangle, you need to call normalize_map_pos on each position and skip
over the non-normal ones.

> Irrespective of that, I would prefere rectangle able to encompass
> real tiles displayed in-water with unreal ones. And I intend to do it
> without using gui-specific line drawing.

I'm not sure what this means.  What does "in-water" mean?  What is
gui-specific line drawing?  Do you know about gui_put_line()?  I think
this is probably the function you should be using.

> So I want to change get_map_xy() and the corresponding
> canvas_pos_to_map_pos() from "void" to "bool", like their reverse
> functions, to check if a set of canvas coordinates visually represent
> a real tile. It'd be a simple patch.

Note entirely simple - there are several different places across 6
different GUIs that will need to be fixed to use the new interface. 
But, this is a good idea - it's been in the works for some time.  But,
this is something I'm interested in doing if you're willing to provide a
patch for it.

As a side note, get_map_xy should be dropped (it's just a wrapper) and
replaced with canvas_to_map_pos() - and the same with get_canvas_xy. 
This is high on my to-do list.  The wrappers may be kept around as
macros in gui-xxx/mapview.c to avoid having to change huge quantities of
code.

> Currently, they just yield nearest_real_pos() and return nothing.

There are two possible ways to do it:

- Call normalize_map_pos and return the result (a bool).
- Don't normalize at all (the caller has to do it).

I have no strong preference for either.  We do need to guarantee that if
normalize_map_pos returns FALSE, the unchanged original coordinates are
returned.  This is not currently a defined property of normalize_map_pos
(but it should be).

jason