You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To be more precise: D-Bus doesn't have the concept of tuples, the construct is called "STRUCT" in the reference, but effectively they're the same as tuples in GVariant, that is, an ordered collection of fields of different known types. (AFAICT GVariant adopted a type system that is partially based on, but not 100% identical to what the D-Bus standard refers to. But since the string format was the closest part to a "standard" on how to represent D-Bus values as text, I chose to try to replicate it within this library.)
It's true though that the function for parsing / formatting Variants don't support structs properly. For formatting, there is #329 which I'll take another look at; parsing would have to be implemented completely freshly and similar to the struct handling when decoding D-Bus messages, we'd have to live with structs being mapped to []interface{}.
Hi,
There doesn't seem to be tuple support in the ParseVariant function, even if the signature contains it.
For example, my understanding of https://docs.gtk.org/glib/gvariant-text-format.html#tuples is that this should work:
However, the tokenization fails with
unrecognized type "(1,2)"
.There is no case for
(
in varLexNormal.Is this a known limitation ? There doesn't seem to be any occurrence of
tuple
in the godbus documentation.https://pkg.go.dev/github.com/godbus/dbus/v5#hdr-Conversion_Rules
Thanks!
The text was updated successfully, but these errors were encountered: