[GRASS-dev] Modules

[Maciej Sieczka]

Glynn Clements wrote:
> 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,

Aha, so that's why width 0 looks the same as 1. In that case, shouldn't
the hint that "0 is finest" be removed from settings dialog?

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

OK. Now that I looked at it carefully I confirm. To avoid confusion,
could the default value be present in the line width dialog?

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

You are right. My bad. Still only the the map being digitised isn't
clipped to the region. The backrop maps are. IMO neither should be clipped.

More:

1. v.digit is changing resolution while zooming, which missalignes the
backdrop raster and vector. Rasters should be displayed at their native
resolution, or at the initial region resolution, which should be
preserved for the whole digitizing session. This bug was present in
v.digt before, too.

2. Now that the point symbols are replaced by bitmaps, width setting
does not affect them. Too bad. But they look better as to their shape
now, which is nice. Could both be achievable?

3. Line segments of the same polyline are rendered kind of separately,
which is particulary visible for segmets at circa 45 degree to each
other with more than 1. The bigger the width, the more visible it is.
Could that be avoided?

4. Tooltips fonts are extremely small.



BTW, not a question to Glynn really: I never understood the "Boundary
(1 area)" and "Boundary (2 areas)" explanations for color settings in
the Symbology tab. Eg., you can have one area, but it will be rendered
with color assigned to "Boundary (2 areas)" (light green, by default).
I suggest replacing "Boundary (1 area)" with "Boundary (broken area)"
and "Boundary (2 areas)" with "Boundary (valid area)". Anybody minds I
change this in CVS?

Maciek