[GRASS-dev] Modules

[Glynn Clements]

Moritz Lennert wrote:

> >> It's looking as if the most practical replacement is going to be to
> >> take the existing v.digit, and replace R_*, D_* and Tcl_* with a real
> >> GUI toolkit.
> > 
> > To this end, I've started refactoring v.digit in the hope of making it
> > easier to use a conventional GUI toolkit.
> > 
> > So far, I've modified attr.c and line.c, corresponding to the
> > following "tools":
> > 
> > 	copy cats
> > 	display attributes
> > 	display cats
> > 	new line
> > 	edit line
> > 	move line
> > 	delete line
> > 
> > Although I've tried to test it as much as possible, I'm not
> > particularly familar with v.digit (never having used it before this
> > week), so I would appreciate it if people who are familiar with it
> > could check that I haven't broken anything (there shouldn't be any
> > user-visible differences as a result of the changes).
> 
> How is this to be understood in relation to v.edit ? Are these 
> complementary ?

It doesn't have any relation to v.edit.

It's related to the possibility of changing v.digit's GUI toolkit from
libraster to something else while retaining the remainder of v.digit. 
Essentially, v.digit would behave in an identical manner, but wouldn't
use XDRIVER.

I don't have any specific toolkit in mind, but every "real" GUI
toolkit (Xt, GTK, Qt, Win32, MFC, wxWidgets, Tk ...) is event driven,
compared to the modal polling loop of R_get_location_with_*. So, I'm
restructuring v.digit into a form which is more suitable for such a
toolkit.

Personally, I'm not sure that writing a replacement digitiser using
v.edit is feasible. Based upon Radim's comments and what I've gleaned
from the v.digit code, you need a monolithic process. Otherwise, you
end up having to re-import the entire map after each change.

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