GNOME Bugzilla – Bug 511814
GUnionVolumeMonitor not clever enough about discovering native volume monitors.
Last modified: 2008-01-28 20:02:07 UTC
GUnionVolumeMonitor implements its vfuncs, such as get_connected_drives() by calling all the vfuncs in any registered G_TYPE_NATIVE_VOLUME_MONITOR, by doing this in get_default_native_class(): monitors = g_type_children (G_TYPE_NATIVE_VOLUME_MONITOR, &n_monitors); That seems excessive and overly simplistic because - It will cause vfuncs to be called for any derived GVolumeMonitors, even those ones that are just derived by language bindings without adding different volume monitoring capability. Generally the original base class's vfunc will then just be called again, and this unnecessary repeat call will presumably have an IO performance penalty in some cases. - Just registering a GVolumeMonitor type without setting the vfuncs will crash any use of, for instance, g_volume_monitor_get_connected_drives() in my application. I don't know what the correct solution is. I imagine that these types should be explicitly registered as being for use in GUnionVolumeMonitor instead of using this short-cut.
I'm not sure what would be a better way... We could check for directly derived types perhaps.
Hmm, but g_type_children() is already only listing directly derived types, no ? So why would grandchildren ever appear on that list ?
It's a problem even if it only returns directly-returned types, because gtkmm derives it's "gtkmm_GVolumeMonitor" directly from "GVolumeMonitor". (And it's probably a problem that it doesn't return non-directly returned types because people should theoretically be allowed to derive GVolumeMonitors from other monitors.) I would just have register_native_volume_monitor() and get_native_volume_monitors() functions, without abusing the GType system for this purpose. We can work around this problem in gtkmm (denying the ability to derive from Gio::VolumeMonitor), but the use of g_type_children() is an unpleasant hack and not every language binding will be able to work around the problem so easily.
Note to self: Actually gtkmm doesn't yet have a way to workaround this. We'll have to add a _DO_NOT_DERIVE_GTYPE macro that sets a bool to stop the call of register_derived_type() in the _PCC_CLASS_IMPLEMENTATION() macro in class_shared.m4. Hopefully we won't end up overwriting part of the original GType's klass instance in our initialization.
I fixed this in glib by adding a registration mechanism for extension points instead of misusing g_type_children()
Many thanks. I heart you.