This commit enhance `module-default-routes` so that the route properties
(such as volume, channel map...) are saved on modification, and re-applied
each time a particular route is selected.
This commit adds a WirePlumber module which stores the current route for
a given device, and implements the necessary interfaces to restore those
on startup.
The routes are stored as an array of objects in JSON format.
Please note that actually restoring routes on startup is not done by this
module but will be implemented separately in a future commit.
now that interest is declared on G_TYPE_OBJECT by default
(in optional Interest function arguments), this conditional default
no longer works as expected...
besides, it may be confusing to have a different default depending
on the interest type
it makes no sense to specify the type when calling, for instance,
session:lookup_endpoint() or similar functions
it also makes it easier to use iterate or lookup in the object
manager, when we already know the type of the objects that the om
contains
Add the ability to construct an Interest argument without
using the Interest keyword, so instead of:
om:lookup(Interest { type = "session" })
we can now write:
om:lookup { type = "session" }
... and also remove lookup_filtered from ObjectManager
If 'move' is set to true, endpoints will be moved to the new target when the
metadata 'target.node' key is present. If 'follow' is set to true, endpoints
will be moved to the newly changed default device automatically.
The == are not valid checks to appear in a .pc file, apparently,
and this breaks the generated wireplumber-0.4.pc file that copies
these version checks as they appear in meson.build
When an Array or Choice that contains Spa:Id appears as a value for an object
field, it is possible to retrieve the Id type from that object field type.
* the type checks were wrong, it was requiring the key to be string
and the value integer
* add the ability to use "any" or "all" for a key, saving us the trouble
of passing -1 from lua (int64) into a uint32 (ugh!)
* use a GArray instead of manual malloc/realloc
* allocate the array as late as possible, to minimize the risk of leaking
its memory if we hit luaL_error()
* skip the shebang before loading the file in the interpreter,
as # is not a valid lua comment
* allow loading scripts with a relative path in interactive mode
The advantage is that luaL_tolstring behaves the same as the native lua
tostring() function, while lua_tostring() does not. In particular, boolean
values are converted properly to "true" and "false" now, while they were
not converted with lua_tostring()
Add a unit test too
When we convert from a lua table to a GVariant dictionary, it is not
possible to maintain the hybrid string & integer keys approach that Lua
has for tables, so we convert all keys to strings and a table becomes a{sv}
When we convert back from a{sv} to a table, it is desirable to get back
the integer keys wherever possible.
The use case is to pass "arrays" (i.e. tables with integer keys) from
the configuration files to the lua scripts, without losing the properties
of the "array"
