[GRASS-dev] Modules

[Glynn Clements]

Maciej Sieczka wrote:

> >> 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?

Odd. I initially suspected that Tk may have a different interpretation
of "width" compared to X etc. However, having traced the Tk drawing
routines with GDB, I can confirm that the width entered in the
Settings dialog is passed directly[1] into the X GC.

That would explain why I can't perceive any difference in the handling
of the line width between the original v.digit and the new version. I
have no idea what's going on at your end.

[1] It forces a minimum width of 1, and rounds to the nearest integer
(Tk's width can be a float). Neither of these should make any
difference, AFAICT.

The default width is 3, BTW.

> >> 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.

Er, I haven't changed anything since that comment. Right now, the map
being digitised (which is "drawn" by v.digit) isn't clipped to the
region. OTOH, the various commands passed to the bgcmd= option have
their own behaviour (e.g. d.vect will clip with render=g or render=c,
but not with render=r or render=d).

> 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)?

Done.

-- 
Glynn Clements <glynn at gclements.plus.com>