Object Interest — WirePlumber 0.5.10 documentation

# Object Interest

The Interest object allows you to declare interest in a specific object, or a set of objects, and filter them. This is used in the ObjectManager but also in other places where methods allow you to iterate over a set of objects or lookup a specific object.

Interest is a binding of `WpObjectInterest`, but it uses a Lua-idiomatic way of construction instead of mapping directly the C functions, for convenience.

## Construction

The most common use for Interest is in the ObjectManager, where you have to use the following construction method to create it.

Interest(decl)
  Parameters:

    decl (table) – an interest declaration

  Returns:

    the interest

  Return type:

    Interest (`WpObjectInterest`)

The interest consists of a GType and an array of constraints. It is constructed with a table that contains all the constraints, plus the GType in the `type` field.

    local om = ObjectManager {
      Interest {
        type = "node",
        Constraint { "node.name", "matches", "alsa*", type = "pw-global" },
        Constraint { "media.class", "equals", "Audio/Sink", type = "pw-global" },
      }
    }

In the above example, the interest will match all objects of type `WpNode` that contain the following 2 global properties:

> - “node.name”, with a value that begins with the string “alsa”

> - “media.class”, with a value that equals exactly the string “Audio/Sink”

When an object method requires an Interest as an argument, you may as well directly pass the declaration table as argument instead of using the `Interest()` constructor function. For instance,

    local fl_port = node:lookup_port {
      Constraint { "port.name", "equals", "playback_FL" }
    }

In the above example, we lookup a port in a node. The `Node.lookup_port()` method takes an Interest as an argument, but we can pass the interest declaration table directly. Note also that such a method does not require declaring the `type` of the interest, as it has `WpPort` as a hardcoded default.

### The type

The type of an interest must be a valid GType, written as a string without the “Wp” prefix and with the first letter optionally being lowercase. The type may match any wireplumber object or interface.

Examples:

type string | parsed as
--- | ---
node | WpNode
Node | WpNode
device | WpDevice
plugin | WpPlugin
siLink | WpSiLink
SiLink | WpSiLink
properties | WpProperties

### The Constraint

The Constraint is constructed also with a table, like Interest itself. This table must have the following items in this very strict order:

> - a subject string: a string that specifies the name of a property to match

> - a verb string: a string that specifies the match operation

> - an object, if the verb requires it

The verb may be any verb listed in `WpConstraintVerb`, using either the nickname of the enum or the character value of it.

Allowed verbs:

nickname | character | value
--- | --- | ---
“equals” | “=” | `WP_CONSTRAINT_VERB_EQUALS`
“not-equals” | “!” | `WP_CONSTRAINT_VERB_NOT_EQUALS`
“in-list” | “c” | `WP_CONSTRAINT_VERB_IN_LIST`
“in-range” | “~” | `WP_CONSTRAINT_VERB_IN_RANGE`
“matches” | “#” | `WP_CONSTRAINT_VERB_MATCHES`
“is-present” | “+” | `WP_CONSTRAINT_VERB_IS_PRESENT`
“is-absent” | “-” | `WP_CONSTRAINT_VERB_IS_ABSENT`

The values that are expected for each verb are primarily documented in `wp_object_interest_add_constraint()`. In Lua, though, native types are expected instead of GVariant and then they are converted according to the rules documented in the GObject Integration page.

Examples of constraints:

    Constraint { "node.id", "equals", "42" }
    Constraint { "node.id", "equals", 42 }
    Constraint { "port.physical", "=", true }

    Constraint { "audio.channel", "not-equals", "FL" }

    Constraint { "node.name", "matches", "v4l2_input*" }
    Constraint { "format.dsp", "#", "*mono audio*" }

    -- matches either "default" or "settings" as a possible value for "metadata.name"
    Constraint { "metadata.name", "in-list", "default", "settings" }

    -- matches any priority.session between 0 and 1000, inclusive
    Constraint { "priority.session", "in-range", 0, 1000 }

    -- matches when the object has a "media.role" property
    Constraint { "media.role", "is-present" }

    -- matches when "media.role" is not present in the properties list
    Constraint { "media.role", "is-absent" }

### Constraint types

PipeWire objects have multiple properties lists, therefore constraints also need to have a way to specify on which property list they apply. The constraint type may be any of the types listed in `WpConstraintType` and can be specified with an additional field in the Constraint construction table, called `type`.

For instance:

    Constraint { "node.id", "equals", "42", type = "pw-global" }
    Constraint { "api.alsa.card.name", "matches", "*Intel*", type = "pw" }
    Constraint { "bound-id", "=", 42, type = "gobject" }

Valid types are:

type | value
--- | ---
pw-global | `WP_CONSTRAINT_TYPE_PW_GLOBAL_PROPERTY`
pw | `WP_CONSTRAINT_TYPE_PW_PROPERTY`
gobject | `WP_CONSTRAINT_TYPE_G_PROPERTY`

## Methods

Interest.matches(self, obj)

  Binds `wp_object_interest_matches()`

  Checks if a specific object matches the interest. The object may be a GObject or a table convertible to `WpProperties`, if the interest is for properties.

  This is rarely useful to use directly on objects, but it may be useful to check if a specific table contains key-value pairs that match specific constraints, using “properties” as the interest type and passing a table as the object.

  Parameters:

    - self – the interest

    - obj (GObject or table) – an object to check for a match

  Returns:

    whether the object matches the interest

  Return type:

    boolean