> Perhaps here (at step 3) is where you should pursue a different method,
Which approaches would you like to suggest? > since the immutable GVariant all by itself is clearly not suitable for your > purpose I agree to this view partly because I consider also further dependencies on my preferred abstraction level of dedicated (C++) classes. > (and convincing glib maintainers to make it mutable is not going to work, ... Please be a bit more careful with your interpretation of my intention. The affected APIs can be kept with the immutable object style. I suggest "only" to extend the existing GVariant interface. I imagine that I would need an additional function "g_variant_get_child_type" for my function draft "g_variant_new_nothing_from_type". It seems that I do not understand the implementation of the function "g_variant_get_child_value" good enough so far to derive a different one for my needs. http://git.gnome.org/browse/glib/tree/glib/gvariant-core.c?id=7c9884476085ceb3fc91cd2eb0374543e79a6e56#n938 I would appreciate your support and further clarifications. Regards, Markus _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
