Martin Dobias wrote:
> > I think copying the implementation could make it even worse as we > would need to watch any changes in GRASS implementation of such > functions. Or did you mean to copy it inside GRASS? Yes, that's what I was actually thinking about: an additional library to be bundled with GRASS that provides "non-fatal" versions of the functions a GUI most likely needs to call and handle. Let's call it "GUI handler lib". BUT, instead of duplicating code: make renamed copies of the functions in question in the same C file that return an int instead of calling G_fatal_error and replace the current G_open_* etc. with wrappers that catch the return value, than exit as appropriate. Then, put another wrapper into the "GUI handler lib" that provides a non-exiting wrapper to be called by QGIS. That way, QGIS developers will always be able to rely on the functions inside "GUI handler lib" to not trigger fatal errors and we don't need to keep two different files updated. We can keep adding functions to the "GUI handler lib" as needed. > > I've fixed the problem using setjmp/longjmp functions as Glynn suggested. So does that give you any bad side-effects? It sounds rather like a hack. Which leads to option 2: create a global variable that controls whether fatal errors should trigger an exit() or not and make all GRASS C API functions that potentially call G_fatal_error() respect this. However, I think this may create a lot of unpredictable behaviour (!?) Maybe it would be enough to modify G_fatal_error() in that case? > > Even better would be to make a list of GRASS functions which could end > with fatal error. Now it's fixed only for that particular know case > where it was terminating QGIS, but I guess there might be more such > functions... That should be a simple grep job ;) > The problem is that GRASS support for QGIS was in fact Radim's one-man > project. Now he's not active in development, so GRASS plugin doesn't > get enough attention from developers. We would really welcome anyone > interested in taking care of the GRASS plugin in QGIS. > Yes, I realize that. I am very interested in developing the QGIS GRASS interface further. My current job does not leave me enough time to do that. However, next spring I will start a new contract where I can exclusively focus on OS GIS development more or less full-time. I am very excited about this and hope I will be able to contribute more to both GRASS and QGIS then. For now, we'll have to do with the small resources we have, be patient and above all work together. The prospect of having a perfectly stable GRASS kernel running underneath a slick cross-platform desktop GUI is just too important to lose sight of over design issues. Best, Benjamin -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
