Hello, the modified signal on SPNamedView is emitted when someone sets the attribute of doc->rroot to sodipodi:modified.
How can I connect to this signal the sigc++ way? Or, what to replace
g_signal_connect (G_OBJECT (namedview), "modified", G_CALLBACK (fun), this); sp_signal_disconnect_by_data (G_OBJECT (namedview), this);
with if I don't like it the old way?
ralf
Quoting Ralf Stephan <ralf@...748...>:
Hello, the modified signal on SPNamedView is emitted when someone sets the attribute of doc->rroot to sodipodi:modified.
How can I connect to this signal the sigc++ way? Or, what to replace
g_signal_connect (G_OBJECT (namedview), "modified",G_CALLBACK (fun), this); sp_signal_disconnect_by_data (G_OBJECT (namedview), this);
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.
-mental
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 - it is not possible to do so?
I was hesitating with the conversion because I didn't see where it is emitted. Atm, it appears to be emitted by calls to sp_repr_set_attr (doc->rroot, "sodipodi:modified", "true");
Thanks! ralf
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
- 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 does not suffice IMHO, and therefore, your instructions (which are fine for isolated classes) will not work with SPNamedView because
- convert all g_signal_emit(..., "modified", ...) calls on
SPNamedViews to emissions of the sigc++ signal instead (except the one in the special handler)
there is no such thing as an explicit call to g_signal_emit (namedview, ... "modified");
because this goes all (and funnily, twice) through SPObject::emitModified. Test case:
with gdb, set breakpoint at sp_desktop_widget_namedview_modified, start up, then press #
The only way to catch this would be, in SPObject::emitModified(), to scan the calls if the object is a namedview, and if so, call its own (sigc++) emit function. Ugly but possible. Do you agree?
ralf
Quoting Ralf Stephan <ralf@...748...>:
The only way to catch this would be, in SPObject::emitModified(), to scan the calls if the object is a namedview, and if so, call its own (sigc++) emit function. Ugly but possible. Do you agree?
No. That's just unnecessarily nasty. You simply need to perform the procedure for SPObject instead of SPNamedView specifically. At least up through step 2, and perhaps some work on step 3 as required.
In this case steps 4 and up are pretty heavy work that I would not recommend doing separately from HEAD, because of the associated integration burden, and perhaps the required prior experience with large refactorings of this kind.
-mental
participants (2)
-
unknown＠example.com -
Ralf Stephan