Quoting Ralf Stephan <ralf@...748...>:
If namedview's modified signal were a sigc++ signal, then you
would
need to remember the sigc::connection returned by the connect() method, and then call disconnect() on that later.
You mean:
- it is, in fact, possible to make namedview modified a sigc++ signal, or
Yes, it is possible to do so.
Generally I approach such things in an incremental manner:
1. create an additional sigc++ 'modified' signal in SPNamedView
[ note! if SPNamedView is still GObject-based, you MUST:
* explicitly call the signal object's constructor in sp_namedview_init(), via placement new * explicitly call the signal object's destructor in sp_namedview_finalize(), or whatever that's called
...this is because GObject bypasses the normal C++ member initialization/cleanup machinery ]
2. in sp_namedview_init(), connect a special handler to the sigc++ signal which simply emits the GObject "modified" signal with the same arguments
3. convert all g_signal_emit(..., "modified", ...) calls on SPNamedViews to emissions of the sigc++ signal instead (except the one in the special handler)
4. convert all g_signal_connect*(..., "modified", ...) calls on SPNamedViews to connections to the sigc++ signal
5. get rid of the special handler and remove SPNamedView's GObject "modified" signal altogether
Note that I would reserve step 5 for after you have merged your code back to HEAD (at which point you may find yourself needing to perform step 4 again first, because of new uses of "modified" which had not entered your tree).
Incidentally, I hope you are planning to merge as soon as HEAD unfreezes after the 0.43 release? Once the freeze is lifted, you will quickly begin to accumulate a large amount of "integration debt" which will make integration increasingly painful the longer it is delayed...
-mental