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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
