I didn't know this class existed I swear :) . Anyway, you're totally right, this unconditionalunblocking in my example would definitely have led to problems. Is there any specific reason why you store a pointerinstead of a reference to the connection? Just curious...

Regards, Markus

-----Ursprüngliche Nachricht----- Von: Jon Cruz [mailto:jon@...18...] Gesendet: Sonntag, 9. März 2014 21:47 An: Markus Engel; Martin Owens Cc: Inkscape Developer Mailing List Betreff: Re: [Inkscape-devel] Blocking Signals

On Mar 9, 2014,at 1:39 PM, Markus Engel wrote:

Hi, if you wantto use this, I'd suggest creating a class like this: classsignal_blocker { public:

http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/util...

Good thinking.However there is another common problem. If you block a signal, then callanother function or so that end up also blocking the signal, then the lattercode will unblock the signal early.

The coderecently added in signal-blocker.h addresses this by checking at constructiontime and only blocking if it is not already blocked. Then as it is destructedit only unblocks if the instance blocked to begin with.

However, we doneed to take care on when and where we block, and to minimize issues. Oneapproach is to block signals. Another is to not cause signals to be emitted inthe first place. We've had need of both those plus a few more in fixingproblems in our codebase.