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