[GRASS-dev] Issues of 6.5 build on WinXP

[Glynn Clements]

Michael Barton wrote:

> I've looked at the current version of menuform.py and gselect.py and can
> find no place that should generate a pause or autocomplete in map
> selection. If it's there, it's really buried deeply.

Everything in the GUI is buried deeply ;)

But, here goes:

Each modification to the text widget generates EVT_TEXT, which calls
cmdPanel.OnUpdateSelection(), which eventually (and by means which I
really don't understand) ends up calling:

1. ColumnSelect.InsertColumns() in gselect.py, which creates a
VectorDBInfo(), which ends up calling grass.vector_db (which runs
"v.db.connect -g") and grass.db_describe (which runs
"db.describe -c"). This is called five times.

2. LayerSelect.InsertLayers() in gselect.py, which calls
GetVectorNumberOfLayers() in utils.py, which runs
"v.category option=report". This is called twice.

AFAICT, this is done to populate the combo boxes for options whose
values are column names or layer numbers respectively.

While I can see why this might be useful:

1. It probably shouldn't be done for every keystroke. Either do it on
focus-out events, or use an idle timer. Or populate the combo boxes
when they are popped up or gain focus, rather than keeping them
populated at all times.

2. It should first check that the map exists (using a list generated
when the dialog is first created), and only perform updates when the
map name changes from valid to invalid, invalid to valid, or from one
valid name to another.

3. The column and layer information should be cached, so that the
commands are run (at most) once for each update rather than once for
each combo box. A dictionary keyed by (qualified) map name would allow
commands to be run at most once even if the same name occurs
repeatedly (e.g. if the user deletes a portion of the name).

Beyond that: the GUI is far too complex for its own good. In
particular, the "producer - queue - consumer thread" mechanism makes
it particularly hard to follow program flow.

As it stands, I wouldn't be optimistic about finding anyone else
willing to share the burden of development and maintenance. For
something this complex with a highly ad-hoc development process,
allocating 50% of the development effort to re-factoring wouldn't be
overkill.

Or you could just rip out 75% of the code. The end result wouldn't be
as featureful, but it would probably be more robust, and less likely
to simply collapse under its own weight when the developers tire of it
and no-one else is willing to step in.

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