On 10/25/07, Benjamin Ducke <[EMAIL PROTECTED]> wrote: > > > 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.
That sounds reasonably, I guess that also other 3rd party tools which use GRASS would appreciate this. > > 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. I think if one takes care, there are no bad side effects. However using setjmp and longjmp generally makes the code harder to understand as it changes usual execution. In C++ you must be even more careful about the jumps because longjmp skips destructors of C++ classes created on stack, so this may lead to some bad behaviour. > 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? No idea about this. However until now (versions < 6.3) when there was custom error routine, G_fatal_error didn't call exit() and everything was fine (at least it seemed so). > > 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. That would be great! > 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. True, true :) Martin _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
