On Sun, 2014-03-09 at 13:46 -0700, Jon Cruz wrote:
The code recently added in signal-blocker.h addresses this by checking at construction time and only blocking if it is not already blocked. Then as it is destructed it only unblocks if the instance blocked to begin with.
However, we do need to take care on when and where we block, and to minimize issues. One approach is to block signals. Another is to not cause signals to be emitted in the first place. We've had need of both those plus a few more in fixing problems in our codebase.
Some really good answers here. I guess we should take a look at the specific code example:
http://bazaar.launchpad.net/~inkscapebrony/inkscape/inkscape/view/head:/src/...
Line: 498 Code:
ObjectsPanel::_setCompositingValues(SPItem *item) { //Block the connections to avoid interference _opacityConnection.block(); _blendConnection.block(); _blurConnection.block();
....
_blurConnection.unblock(); _blendConnection.unblock(); _opacityConnection.unblock(); }
In this case, it seems it might be doing the wrong thing. The blocking class is what's needed instead.
BTW: This object dialog and other code could always use more review too: https://code.launchpad.net/~inkscapebrony/inkscape/inkscape/+merge/209579
Best Regards, Martin Owens