First set the properties in the object itself and then copy them
over to the global. This ensure that the global properties are
also in the object and makes code a bit cleaner.
It also make it possible to use the global id to make the property
values unique, if we want to later .
PIPEWIRE_CORE can be used to specify a server name.
PIPEWIRE_REMOTE can be used to specify what server name to
connect to.
Either use the absolute path of the name to create and connect
to a server, or use a relative path. For a relative path, the
server name will be completed by prefixing the following paths
in order:
PIPEWIRE_RUNTIME_DIR environment variable,
XDG_RUNTIME_DIR environment variable,
HOME environment variable,
USERPROFILE environment variable,
home directory as stored in the password database.
Fixes#259
First use the configured properties, then use the env variables.
Make the daemon use the env variable by default.
This makes it possible to start servers with PIPEWIRE_CORE env variable
names but still override with the command option.
Makes it possible to make apps connect to PIPEWIRE_REMOTE env by
default and allows you to override with the command option.
This access module now only checks if the connection is comming
from the portal and tags the ACCESS property with portal in that
case. It will no longer do permission store checks, that's for
the session manager.
Pass the node_data around instead of the proxy. Get the proxy from
the node data.
Allocate user_data before the node_data so that the caller can
use the proxy user_data without overwriting the node_data.
This makes it easier to test PipeWire in its "as-installed" state,
for example in an OS distribution.
The .test metadata files in ${datadir}/installed-tests/${package} are
a convention taken from GNOME's installed-tests initiative, allowing a
generic test-runner like gnome-desktop-testing to discover and run tests
in an automatic way.
The installation path ${libexecdir}/installed-tests/${package} is also
a convention borrowed from GNOME's installed-tests initiative.
In addition to the automated tests, I've installed example executables
in the same place, for manual testing. They could be separated into
a different directory if desired, but they seem like they have more
similarities with the automated tests than differences: both are there
to test that PipeWire works correctly, and neither should be relied on
for production use. Some examples are installed in deeper subdirectories
to avoid name clashes.
Signed-off-by: Simon McVittie <smcv@debian.org>
Fix up clients that say they have fixed properties while in fact
they are not. Assume that when there are alternatives, the property
was in fact not fixed.
When a resource is doing an operation that sets the client in the busy
state, make sure we unblock the client again when the resource is
destroyed before we could complete the operation or else the client
is stuck forever.
