[GRASS-dev] Issues of 6.5 build on WinXP

[Michael Barton]

On Dec 31, 2009, at 5:39 AM, Glynn Clements wrote:

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

Where is the EVT_TEXT binding? I couldn't find it.

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

It seems that this should be run at some other time than when a map is being selected.

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

This should be run when needed, not while typing.

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

I agree with the above

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

Maybe not 75%, but possibly quite a bit. Robusticity and a view toward ensuring that other volunteers can manage this in the future is very important.

Michael

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