[GRASS-dev] suggested temporary feature freeze for wxGUI

[Michael Barton]

Seeing all the recent bug reports coming in for the new wxPython GUI  
is frustrating...not because of the testing or reports, which are very  
good to have, but because almost all of these features worked  
previously.

This is a function of the complexity of the GUI. Unlike command  
modules, it involves a very large amount of code that is very tightly  
interlinked in sometimes not very obvious ways--even to those of us  
who are writing it. A feature or even a bug fix added in one place can  
cause a cascade of effects elsewhere and break something that seems  
completely unrelated.

At the moment, the GUI is pretty complete in giving a user interface  
to all of GRASS. So I suggest that this is a good time to stop adding  
new things and try to make sure all the things we already have work  
well. Obviously we should keep accumulating ideas for enhancements and  
new features, but simply try to resist the temptation to try to  
implement them.

It seems to me that we need to focus especially on 3 areas at the  
moment:

1) basic bug fixing. These are things that throw an error or do not  
work as designed.

2) increasing robusticity. This is trickier, but I'm thinking of  
situations where a feature works fine under normal circumstances, but  
can fail or give an error under abnormal circumstances like repeated  
mouse clicking, odd combinations of actions, etc. These are harder to  
find and fix. But we need to make the GUI as unbreakable as possible.  
Some of this is adding more error traps so that abnormal circumstances  
may break something, but will do so gracefully.

3) multi-platform support. Somethings worked (and still work) fine on  
my Mac or Martin's Linux flavor, but don't work so well on other  
systems. Some important pieces like the digitizer and new nviz modules  
do not even compile on Mac and Windows. It's been an amazing piece of  
work to get to the point where we have advanced capabilities like  
these functional at all. But we now need to make them available to all  
GRASS users.

Doing these things will give us a dependable and very usable UI for  
GRASS. This is very important if we want to make this a viable  
alternative GUI for GRASS 6.4 and the only one for GRASS 7.

After this work, I suggest that we take a look at some of the  
underlying algorithms for getting maps rendered and displayed, given  
the rewrite of the display architecture going on now for GRASS 7. Some  
of this has already been started and it may turn out that only tweaks  
are needed. But we should take a hard look at this before going on to  
make sure that this is a solid system down the line.

Then we can start in on the backlog of enhancement and feature  
requests. But we should implement them very carefully and with a lot  
of testing from now on to avoid breaking this increasingly complex code.

With a busy academic year already starting, I'm finding much less time  
to work on the GUI and I suspect that Martin's term is nearing  
beginning too. So the less developer time available, also makes this a  
good time for getting caught up with where we are now.

I'd like to appeal for some help from you folks especially for the  
cross-platform implementation issues. Most of these are C, C++, or  
compilation related. These are areas where I do not have expertise to  
do much. Martin has done a fantastic job of adding some sophisticated  
new modules--especially for digitizing and multi-dimensional  
visualization. It would be great if someone(s) could help get the  
cross-platform issues of these modules worked out.


Cheers
Michael