Using dbus.service.signal decorator
Simon McVittie
smcv at collabora.com
Fri Jun 16 16:24:45 UTC 2017
On Wed, 14 Jun 2017 at 20:51:20 +0200, Bogdan Lotko wrote:
> @dbus.service.signal('myInterface', 'v(sav(iii))' )
> def mySignal(self, message):
...
> e.mySignal( ('myString', [(1, 1, 1)]) )
The signal decorator says you will send two arguments: the first is a
variant, and the second is a struct (tuple) with 3 elements. Like this:
- message containing:
- variant (containing anything, by definition)
- struct containing:
- string
- array containing 0 or more:
- variant (containing anything)
- tuple containing:
- int32
- int32
- int32
(Messages have 0 or more arguments, each represented by a "single
complete type" in the signature. See the D-Bus Specification for
the definition of a single complete type.)
The sample signal emission looks as though in fact you intended to send
something more like this:
- message containing:
- tuple containing:
- string
- array containing 0 or more:
- tuple containing:
- int32
- int32
- int32
I think you have misunderstood the D-Bus type system; my guess is that
you have misunderstood how 'v' works. At a high level, what is it that
you intended to send? Writing it in the same form as the indented
versions I wrote above might help.
Regarding the sample signal emission, having a tuple as a top-level
argument of a message is a "code smell": if you know you are sending a
string and an array, why are they not separate arguments of the message?
Regarding the signature, having a tuple directly nested inside another
tuple is also a "code smell", because you could remove one layer of
nesting without losing any expressiveness.
S
More information about the dbus
mailing list