[GRASS-dev] Modules

[Glynn Clements]

Maciej Sieczka wrote:

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

BTW, X does the same.

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

Maybe.

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

The same applies to other settings (snap distance, etc).

There should probably be a bunch of lines like the following in
tool_centre()[1]:

	sprintf(buf, "%d", var_geti( VAR_LINEWIDTH ));
	Tcl_SetVar(Toolbox, "GVariable(linewidth)", buf, TCL_GLOBAL_ONLY);

[1] This should probably be "tool_center"; GRASS function/variable
names normally use US English.

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

The background images depend upon the behaviour of individual d.*
programs. The programs are run with GRASS_WIDTH and GRASS_HEIGHT set
to the dimensions of the window, and the region set by the user
(through the various zoom/pan tools).

Like the previous version, the region isn't "adjusted" to match the
window's aspect ratio. If desired, I can re-instate clipping of the
vector map being digitised. Anything else is unrelated to the change
from libraster to Tk, and should be filed as a wish.

Eliminating the use of libraster doesn't mean that I want to become
v.digit's maintainer. Once I've fixed anything which I broke during
the change, my work on v.digit is done.

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

Only if someone wants to create multiple versions of each bitmap.

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

Only with significant structural changes.

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