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