Add GVariant bindings for non-basic types, nested types: arrays, tuples, dicts, ...

[gkoz]

We don't have 'em yet.

[sdroege]

While general GVariant support is there since a while, what is missing is support for non-basic, nested types: arrays, tuples, dicts, etc.

[wmanley]

I've been working on a pure rust implementation of GVariant: source, docs, crate.

The design is a little different to GLib's in that the type signatures must be known at compile time. The behaviour of the crate matches GLib's, at least for all data in "normal form".

I'm preparing to release version 1.0: ostreedev/gvariant-rs#1 but before I do I'd like to get some feedback. Specifically:

@sdroege: could you comment on what it would take for the glib-rs docs to recommend using the gvariant crate instead of the bindings to the GLib GVariant implementation?

If the answer is "not going to happen" that's fine too, I'll just stop worrying about it.

[sdroege]

@sdroege: could you comment on what it would take for the glib-rs docs to recommend using the gvariant crate instead of the bindings to the GLib GVariant implementation?

@wmanley There's also zvariant, which unlike yours also provides serialization support and has serde integration. We could probably list native Rust alternatives in the docs (also zbus instead of GDbus once bindings for that are there), do you want to prepare a PR for that?

We should still provide proper GVariant bindings here, independent of all that.

[wmanley]

@wmanley There's also zvariant, which unlike yours also provides serialization support and has serde integration.

Note: ZVariant is an implementation of the DBus wire format, not GVariant. The docs say "GVariant is also very common and will be supported by a future version of this crate.". I discuss other implementations in the docs of the gvariant crate: https://docs.rs/gvariant/0.2.0/gvariant/#comparison-to-and-relationship-with-other-projects

We could probably list native Rust alternatives in the docs (also zbus instead of GDbus once bindings for that are there), do you want to prepare a PR for that?

Will do.

[zeenix]

@wmanley I'm working on GVariant support in zvariant this week. I'm hopeful that it can be done w/o breaking any API. If you'd like to help in this regard, you can add the missing GVariant bindings here so I can use them in my tests.

[zeenix]

Note: ZVariant is an implementation of the DBus wire format, not GVariant.

Yeah but GVariant support is very much planned from beginning and hence the reason zvariant is separate from zbus crate. Nobody uses D-Bus format for anything other than D-Bus AFAIK so w/o GVariant support, zvariant as a crate is not very useful.

[wmanley]

@wmanley I'm working on GVariant support in zvariant this week. I'm hopeful that it can be done w/o breaking any API. If you'd like to help in this regard, you can add the missing GVariant bindings here so I can use them in my tests.

To test my implementation I used cargo fuzz to compare against the GLib version by using glib-sys directly. I can highly recommend cargo fuzz if you weren't already planning on using it. You may find this useful: https:/wmanley/gvariant-rs/blob/master/fuzz/fuzz_targets/fuzz_target_1.rs

[zeenix]

I can highly recommend cargo fuzz if you weren't already planning on using it. You may find this useful: https:/wmanley/gvariant-rs/blob/master/fuzz/fuzz_targets/fuzz_target_1.rs

Thanks. I'll have a look. :)

To test my implementation I used cargo fuzz to compare against the GLib version by using glib-sys directly.

Hmm.. I could also do the same but it would be best if glib-rs gains the missing GVariant API as a side-effect of this effort.

[wmanley]

This may also be of interest: https://gitlab.gnome.org/GNOME/glib/-/issues/2121

[zeenix]

@wmanley Looking into container types now, array being the first one. I'm a bit unclear about how to find the framing offset size. Do I understand correctly from your code that:

• offset size is determined through the size of the entire array, which include the offset bytes?
• the leading padding (before the array) is not included in the equation? I'm pretty sure about this one but would be good to have a second opinion.

[wmanley]

@wmanley Looking into container types now, array being the first one. I'm a bit unclear about how to find the framing offset size. Do I understand correctly from your code that:

• offset size is determined through the size of the entire array, which include the offset bytes?

Yes. This makes reading easy, but complicates writing.

• the leading padding (before the array) is not included in the equation? I'm pretty sure about this one but would be good to have a second opinion.

Correct

[zeenix]

@wmanley many thanks!

[wwmm]

Hi! Is there any way to read/write gsettings arrays in Rust? I am playing with the idea of porting PulseEffects to Rust but we have gsettings keys stored as arrays. For example

<key name="color" type="ad">
        <default>[1.0,1.0,1.0,1.0]</default>
</key>

I was able to read it with this ugly code:

let mut color_string = settings
            .get_value("color")
            .to_string()
            .replace("[", "")
            .replace("]", "")
            .replace(" ", "");

let color_str_vec: Vec<&str> = color_string.split(",").collect();

But I do not see how I could write this array to the gsettings database.

[sdroege]

See #651 which is almost finished but stalled. Feel free to take that over unless @zeenix wants soon

[zeenix]

#651 fixed this I believe.