Implement FromVariant for Variant #679

ids1024 · 2020-09-03T23:30:05Z

This is useful when combined with the container variant functions and trait implementations from #651.

Implementing ToVariant would be useful as well, but isn't currently possible: #678

sdroege · 2020-09-04T07:24:58Z

See #678 (comment) . Can you also add that here for symmetry? :)

sdroege · 2020-09-04T07:26:04Z

src/variant.rs

@@ -725,6 +725,12 @@ where
    }
 }

+impl FromVariant for Variant {
+    fn from_variant(variant: &Variant) -> Option<Self> {
+        Some(variant.clone())


Why this and not Variant::new_variant()? I would expect this to box the variant in another variant (and that the behaviour for glib::Value is currently the same as what you implement here is a bug that I'm going to fix in the near future).

Hm. new_variant() creates a variant of type v instead of the original type. My thought was that it could be useful to use the abstractions in the new container API when one already has a variant of the type one wants, but needs to put it in a tuple or some such.

In any case, I don't think it's new_variant() that should be used here, but rather get_variant(). (new_variant() would be used in ToVariant.)

And I do like how in the code I showed in #678 (comment), I could use this implementation of FromVariant to partially deconstruct a complicated Variant type.

I don't know if there's a clean way to support both.

And I do like how in the code I showed in #678 (comment), I could use this implementation of FromVariant to partially deconstruct a complicated Variant type.

While I agree that this is convenient, this seems more like a hack then a nice solution :) By having this implemented the API is asymmetric and the Variant wrapping is not possible to express anymore.

In any case, I don't think it's new_variant() that should be used here, but rather get_variant(). (new_variant() would be used in ToVariant.)

Indeed, sorry

I've rebased on master and changed to using .variant() and .get_variant().

For my immediate use case, I think the .iter() method is probably a better way to go through a collection variant without fully deconstructing it, so I'm mostly happy with this implementation, supposing the gtk-rs maintainers all agree it should work this way.

Also for having a type that allows deconstructing via a "wildcard", you could add some dummy type that implements the trait and just does nothing, or not?

sdroege

See https://github.com/gtk-rs/glib/pull/679/files#r483437430

@zeenix @GuillaumeGomez Do you have any opinions?

valpackett · 2020-09-06T19:18:32Z

Trying to use the current implementation to access D-Bus property change notifications with their a{sv}:

    dd.connect_local("g-properties-changed", true, move |args| {
        let new_props = args[1]
            .get::<glib::Variant>()
            .unwrap()
            .unwrap()
            .get::<std::collections::HashMap<String, glib::Variant>>()
            .unwrap();
        None
    })

It does work now:

{"TimeToEmpty": Variant { ptr: 0x1eaedcbfd580, type: VariantTy { inner: "v" }, value: "<int64 19200>" }, "UpdateTime": Variant { ptr: 0x1eaed6ac0490, type: VariantTy { inner: "v" }, value: "<uint64 1599419489>" }, "EnergyRate": Variant { ptr: 0x1eaed6a8c260, type: VariantTy { inner: "v" }, value: "<5.6056000000000008>" }, "Energy": Variant { ptr: 0x1eaedcbd5890, type: VariantTy { inner: "v" }, value: "<29.9222>" }}

But I get the aforementioned "boxed" variants and there doesn't seem to be a way to access the inner variant in these, since the instances just return the outer variant itself :/
i.e. I can infinitely chain .get::<glib::Variant>().unwrap().get::<glib::Variant>().unwrap() uselessly

zeenix · 2020-09-06T20:12:00Z

But I get the aforementioned "boxed" variants and there doesn't seem to be a way to access the inner variant in these, since the instances just return the outer variant itself :/

You need to use the get_child_value() method.

valpackett · 2020-09-06T20:13:37Z

Oh. Thanks. idk why I keep staring at docs.rs for the release version expecting it to show something new from a PR.. (or from git from that matter) :D

valpackett · 2020-09-06T20:16:12Z

hmm..

thread 'main' panicked at 'assertion failed: ty.starts_with("a") || ty.starts_with("{") || ty.starts_with("(")', /home/greg/.local/share/cargo/git/checkouts/glib-53370c4288e47ffa/633b61a/src/variant.rs:197:9

valpackett · 2020-09-06T22:24:49Z

(using get_child_value to walk the a{sv} also gets me to these same variants with v inside)

(why do they exist?)

This is useful when combined with the container variant functions and trait implementations from gtk-rs#651. BREAKING CHANGE: This remove `impl<T: ToVariant> From<T> for Variant`, which made it impossible to implement `ToVariant` since it conflicts with the standard library `impl<T> From<T> for T`: gtk-rs#678

sdroege · 2020-09-07T06:50:27Z

src/variant.rs

@@ -529,12 +527,6 @@ impl ToVariant for str {
    }
 }

-impl<T: ToVariant> From<T> for Variant {
-    fn from(value: T) -> Variant {
-        value.to_variant()


This impl also had the problem that it took its argument by value, i.e. took ownership of it and consumed it, but then only used it by reference. This is rather inefficient...

sdroege

Looks good to me. @EPashkin @zeenix @GuillaumeGomez ?

zeenix · 2020-09-07T10:49:23Z

thread 'main' panicked at 'assertion failed: ty.starts_with("a") || ty.starts_with("{") || ty.starts_with("(")', /home/greg/.local/share/cargo/git/checkouts/glib-53370c4288e47ffa/633b61a/src/variant.rs:197:9

Already fixed in master.

(using get_child_value to walk the a{sv} also gets me to these same variants with v inside)

(why do they exist?)

What?

zeenix · 2020-09-07T10:58:00Z

@sdroege sounds good to me.

FWIW, this is what I was doing in zvariant as well but @elmarco insisted that use of std traits rather than our own, was more important than a uniform API to deal with transformation of all types (including Variant itself) to/from Variant type. The huge drawback of not having a uniform API is that user has to be conscious of Variant boxing. So what I'm saying is that I believe this (PR) and custom traits is the best way forward!

valpackett · 2020-09-07T11:00:01Z

@zeenix the v variants were also fixed with the last push (ids1024 force-pushed the ids1024:from_variant branch from 633b61a to f6b61f3 11 hours ago) 👍

sdroege reviewed Sep 4, 2020

View reviewed changes

ids1024 force-pushed the from_variant branch 3 times, most recently from 3e80e14 to 633b61a Compare September 4, 2020 16:54

sdroege suggested changes Sep 6, 2020

View reviewed changes

ids1024 force-pushed the from_variant branch from 633b61a to f6b61f3 Compare September 6, 2020 23:41

ids1024 requested a review from sdroege September 7, 2020 04:02

sdroege reviewed Sep 7, 2020

View reviewed changes

sdroege approved these changes Sep 7, 2020

View reviewed changes

sdroege merged commit c9ee583 into gtk-rs:master Sep 7, 2020

ids1024 deleted the from_variant branch September 8, 2020 03:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement FromVariant for Variant #679

Implement FromVariant for Variant #679

ids1024 commented Sep 3, 2020

sdroege commented Sep 4, 2020

sdroege Sep 4, 2020

ids1024 Sep 4, 2020

ids1024 Sep 4, 2020

sdroege Sep 6, 2020

ids1024 Sep 6, 2020

sdroege Sep 7, 2020

sdroege left a comment

valpackett commented Sep 6, 2020

zeenix commented Sep 6, 2020

valpackett commented Sep 6, 2020 •

edited

Loading

valpackett commented Sep 6, 2020

valpackett commented Sep 6, 2020 •

edited

Loading

sdroege Sep 7, 2020

sdroege left a comment

zeenix commented Sep 7, 2020

zeenix commented Sep 7, 2020

valpackett commented Sep 7, 2020

Implement FromVariant for Variant #679

Implement FromVariant for Variant #679

Conversation

ids1024 commented Sep 3, 2020

sdroege commented Sep 4, 2020

sdroege Sep 4, 2020

Choose a reason for hiding this comment

ids1024 Sep 4, 2020

Choose a reason for hiding this comment

ids1024 Sep 4, 2020

Choose a reason for hiding this comment

sdroege Sep 6, 2020

Choose a reason for hiding this comment

ids1024 Sep 6, 2020

Choose a reason for hiding this comment

sdroege Sep 7, 2020

Choose a reason for hiding this comment

sdroege left a comment

Choose a reason for hiding this comment

valpackett commented Sep 6, 2020

zeenix commented Sep 6, 2020

valpackett commented Sep 6, 2020 • edited Loading

valpackett commented Sep 6, 2020

valpackett commented Sep 6, 2020 • edited Loading

sdroege Sep 7, 2020

Choose a reason for hiding this comment

sdroege left a comment

Choose a reason for hiding this comment

zeenix commented Sep 7, 2020

zeenix commented Sep 7, 2020

valpackett commented Sep 7, 2020

valpackett commented Sep 6, 2020 •

edited

Loading

valpackett commented Sep 6, 2020 •

edited

Loading