Bug 19838 - GVariant support is far from complete
Summary: GVariant support is far from complete
Alias: None
Product: Gtk#
Classification: Mono
Component: gtk-sharp ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-05-15 15:57 UTC by Xavier Claessens
Modified: 2014-06-17 11:50 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Xavier Claessens 2014-05-15 15:57:59 UTC
Binding for GVariant is handwritten and only support basic types. It should support types, arrays, dictionaries.
Comment 1 Xavier Claessens 2014-05-15 15:58:51 UTC
Here is some of them: http://cgit.collabora.com/git/user/xclaesse/gtk-sharp.git/log/?h=variant
Comment 2 Simon McVittie 2014-05-16 09:39:56 UTC
+ static extern IntPtr g_variant_new_tuple (IntPtr children, UIntPtr n_children);
+ public Variant (Variant[] children)

I'm no C# expert, but it seems a bit too subtle that

    var v = new Variant (new Variant[]
        { new Variant ("hello"), new Variant ("world") });

is constructing a two-element tuple (i.e. a pair) analogous to a struct { string a; string b; }, but each of these alternatives:

    var v1 = new Variant (null, new Variant[]
        { new Variant ("hello"), new Variant ("world") });
    var v2 = new Variant (VariantType.STRING, new Variant[]
        { new Variant ("hello"), new Variant ("world") });

is constructing an array of two strings (in v1 the type of the elements is inferred from the elements themselves, which doesn't work for empty arrays, while in v2 it is explicit; the syntax VariantType.STRING is hypothetical, I don't know whether it actually exists in gtk-sharp yet). Perhaps being more explicit about containers would be better:

    var tuple = Variant.NewTuple (new Variant[] { new Variant ("hello"), ...});

    var array = Variant.NewArray (null,
        new Variant[] { new Variant ("hello"), ...});

Context for people who don't speak fluent D-Bus: GVariant is basically the D-Bus data model. It has the following containers:

* variant: wrap an arbitrary variant in another layer of variant
* tuple (called "struct" in D-Bus): specified number and type of elements, elements' types may differ, analogous to a C struct
* array: variable number of elements, all elements have the same specified type, analogous to a C array
* maybe: contains either a variant of a specified type, or NULL (basically implemented as an array of length <= 1)
Comment 3 Simon McVittie 2014-05-16 09:43:17 UTC
+ public Variant (Variant val) : this (g_variant_new_variant (val.Handle)) {}

Similarly, it doesn't seem immediately obvious that this wraps a variant in another layer of variant, rather than being a copy constructor. Perhaps a static method "public static Variant NewVariant (Variant val)" would be clearer.
Comment 4 Xavier Claessens 2014-05-16 10:17:49 UTC
You're probably right, yes. I should make API like in VariantType:

public static Variant NewTuple (Variant[] children);

var v = Variant.NewTuple(new Variant[] {v1, v1});
Comment 5 Xavier Claessens 2014-05-21 15:13:17 UTC
Branch updated with that new API.
Comment 6 Xavier Claessens 2014-05-21 15:23:05 UTC
I also changed the way it's implemented by adding generic from/to array API in GLib.Marshaller. Those new marshallers will be used in my array generator rewrite in bug #19972
Comment 7 Bertrand Lorentz 2014-06-05 11:47:47 UTC
Thanks for working on this !

So, just to check if I'm following correctly: your "variant" branch is now obsolete by the changes in your "array" branch proposed in bug #19972, right ?
Comment 8 Xavier Claessens 2014-06-12 13:28:41 UTC
Actually bug #19972 needs more work because I didn't know that it can do implicit marshalling of arrays.

For the work I'm currently doing I only need the variant part, so I made this branch that can be merged before but #19972:

Comment 9 Bertrand Lorentz 2014-06-13 08:02:10 UTC
I've committed the variant branch to git master, and also added a "NewArray (Variant[] children)" convenience method.

Thanks again !

I think this bug can be closed (I don't have the access rights to do it myself).
Comment 10 Xavier Claessens 2014-06-17 11:50:35 UTC

I discovered a crash, I opened bug #20658.