Radim Blazek wrote: > > This too is Not A Bug. Not isolating distinct operations in distinct > > processes *is* a bug. > > I can imagine almost everything done via GRASS modules. Yes, it is > annoying to run a GRASS module (probably I have to write a new one to > be sure, that the output/options do not change in next minor GRASS > release)
Even if you use an existing module, the module interface is less likely to change than a library function. Certainly, the changes to the modules between 6.x and 7.0 are quite minor compared to the changes to many library functions (e.g. half of G_* being renamed to Rast_*, R_* disappearing, ...). > and to parse output instead of just calling a function. You > did your work well, you made our life harder. > > Everything except vector editing. I don't see any reasonable > possibility to do interactive vector editing via a GRASS module. For > vector editing, I need immediate response which is visualized on > display (e.g. if a vertex was moved and area topology was broken it > must be displayed). It is impossible to open/close a vector for every > single operation, it would take too long time for larger vectors. For this specific case, is it possible to isolate a subset of the vector library such that it can be used reasonably by both GRASS and QGIS (and the wxGUI's vdigit module, which is just as bad in this regard)? Also, what kind of fatal errors can occur while in the middle of vector editing that could reasonably be recovered from? I'm not particularly averse to libraries using status returns, so long as this doesn't: 1. propagate up to the API used by modules, 2. "infest" a large portion of the GRASS libraries, or 3. mean that fatal errors end up being signalled at the highest levels after most of the context has been lost. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
