Re: Q: are specific C marshallers obsolete these days?
Peter Bloomfield <[email protected]>
| Newsgroups | gmane.comp.gnome.apps.balsa |
|---|---|
| Message-ID | <[email protected]> |
Hi Albrecht: On 10/30/2018 04:14:28 PM Tue, Albrecht Dreß wrote: > Hi all, > > while playing with the extension for LibBalsaServer's GET_PASSWORD signal to fix the issue of certificate password retrieval, I stumbled over the use of specific C marshallers for our custom signals. IIRC, they have been used this way since many, many years in Balsa. > > However, the GObject Reference manual, section “How to create and use signals” [1] states: > > “The C signal marshaller should always be NULL, in which case the best marshaller for the given closure type will be chosen by GLib. This may be an internal marshaller specific to the closure type, or g_cclosure_marshal_generic, which implements generic conversion of arrays of parameters to C callback invocations. GLib used to require the user to write or generate a type-specific marshaller and pass that, but that has been deprecated in favour of automatic selection of marshallers.” > > For me, this raises the question whether our custom marshallers are /really/ still needed, and for what reason? > > Cheers, > Albrecht. > > > [1] <https://developer.gnome.org/gobject/stable/howto-signals.html> Thanks for the link--I've never gone through those pages completely! Yes, it seems that we can simplify Balsa code by passing the recommended NULL and letting g_signal_new() figure it out. Then we can drop the marshaller lists, and some clunky build system code for Balsa's custom marshallers. It would simplify maintenance and innovation, with most likely a completely negligible performance hit. I note that the generic marshaller is "Since: 2.30", so that solution has been around only since 2011 or so ☺ Peter _______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
signature.asc
(application/pgp-signature, 195 B)
-----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQS030wPRfNNA5alz3MfX9S1uSp09QUCW9kVdwAKCRAfX9S1uSp0 9eOoAJ4vkdSQ7WdMYW0EsFgEJf5dXozrXgCeKYu0NnmEhhbBFmrt+LK2h7eKRRU= =fcoQ -----END PGP SIGNATURE-----