[GRASS-dev] Modules

[Maciej Sieczka]

Glynn Clements wrote:
> Maciej Sieczka wrote:
> 
>>>> The remaining step is to reinstate the bgcmd= option.
>> bgcmd works. Accepts multiple d.* commands sepearated with ";". Great.
>>
>>> Done; updated patch (again, against CVS HEAD) attached.
>> Issues:
>>
>> 1. Points/centroids/nodes - irregular shape, see the attached points.png.
> 
> I see. I'm passing exactly the same coordinates to the Tk canvas
> widget that were being used with libraster, but it appears that Tk
> interprets them slightly differently. However, I haven't been able to
> determine the appropriate "tweak" to get the two to match.
> 
> Ultimately, we may be better off using bitmaps for icons, so I don't
> want to spend too much time on this.

Aha.

>> 2. Digitize point tool is deselected after digitizing first point; to
>> digitize another point, one has to select the tool again, and so on.
>> Same applies to digitize centroid tool.
> 
> Does this do the right thing?
> 
> --- util.c~	2007-02-22 20:58:16.000000000 +0000
> +++ util.c	2007-02-23 21:34:06.000000000 +0000
> @@ -64,6 +64,7 @@
>      tool_closure = NULL;
>  
>      driver_close();
> +    next_tool();
>  }
>  
>  void cancel_tool(void)

I can see you have aplied it in CVS. I have built from CVS few minutes
ago and now the digitize point/centroid tools work fine.

>> 3. Setting a new line width and redrawing usually doesn't make any
>> difference.
> 
> It works for me. Note that you have to press Return after editing the
> value.

I know about Enter. It seems the problem is that for v.digit width 1
and 0 are the same (and they both look like 0 in v.digit before), and 2
is set by default (which gives circa the same width as 1 used to in
v.digit before). These got me confused. Can you look into it?

>> 4. Region is now handled differently than it used to in v.digit.
>> Previously, the backdrop maps AND the currently digitized map where
>> displayed trimmed to zoom box shape (region_former.png). After your
>> patch, only the backdrop is, while the map being digitized is not
>> (region_patched.png). IMO a solution is to either revert the previous
>> behaviour, or, preferably, make v.digit ignore the region extent, and
>> let it fill the window at maximum (I think this is preffered in case of
>> v.digit - when one is digitising, he wants to see the maximum of it).
> 
> I can do either; the previous behaviour (honour the user's region
> settings, and clip the vector to it) is the easier solution, both in
> terms of implementation and design (I don't want a repeat of the
> discussions regarding gis.m's zoom behaviour).

I can see you have chosen the latter option, which I find more suitable
for digitizing.

There is an issue still that zooming and panning in v.digit changes
region settings. One could maybe live with v.digit changing the region
extent (it has it's uses, though propably most users won't appreciate
it), but changing the resolution should be not allowed I think.

>> 5. Minor glitch: the monitor's title bar.
> 
> That's because it isn't a monitor.

Oh.

> I can set the window title to whatever is desired.

How about: "v.digit: map name" (without the quotes)?

Maciek