On Mon, Jan 18, 2010 at 3:33 AM, Glynn Clements <[email protected]> wrote: >> 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)?
The subset would be almost the whole vector library (Vlib,diglib,rtree). > Also, what kind of fatal errors can occur while in the middle of > vector editing that could reasonably be recovered from? Probably I don't understand the question, for any error I would prefer to give a decent message (in window box) and stop editing (even with corrupted vector) but don't crash the application. > 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, So you would suggest a separate set of functions for modules and QGIS/vdigit? > 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. What is wrong on calling G_fatal_error on each level from the first function where the error happened to the top and optionally (i.e. modules wants exit, qgis/vdigit return value) either only print the message (call error routine) and return error code or exit (it means on the lowest level). Radim _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
