fdo-mirrors/wireplumber
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/wireplumber.git synced 2025-12-20 18:10:13 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
wireplumber/lib/wp/proxy.h

106 lines
2.8 KiB
C
Raw Normal View History

proxy: add API
2019-06-10 15:07:54 -04:00
/* WirePlumber
*
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
* Copyright © 2020 Collabora Ltd.
proxy: refactor the proxy class to hide pipewire API and make things easier
2019-08-22 20:04:39 +03:00
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
proxy: add API
2019-06-10 15:07:54 -04:00
*
* SPDX-License-Identifier: MIT
*/
#ifndef __WIREPLUMBER_PROXY_H__
#define __WIREPLUMBER_PROXY_H__
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
#include "object.h"
proxy: add API
2019-06-10 15:07:54 -04:00
G_BEGIN_DECLS
proxy: refactor the proxy class to hide pipewire API and make things easier
2019-08-22 20:04:39 +03:00
struct pw_proxy;
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
/*!
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \brief Flags to be used as WpObjectFeatures for WpProxy subclasses.
* \ingroup wpproxy
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
*/
proxy: refactor the proxy class to hide pipewire API and make things easier
2019-08-22 20:04:39 +03:00
typedef enum { /*< flags >*/
proxy: refactor how PARAM_Props/PropInfo are handled + rename FEATURE_CONTROLS to FEATURE_PROPS + add accessor for the standard spa_param_info (info->params) + hide the low-level params API that nobody uses
2020-05-25 15:33:47 +03:00
/* standard features */
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
WP_PROXY_FEATURE_BOUND = (1 << 0),
proxy: refactor the proxy class to hide pipewire API and make things easier
2019-08-22 20:04:39 +03:00
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
/* WpPipewireObjectInterface */
WP_PIPEWIRE_OBJECT_FEATURE_INFO = (1 << 4),
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_PROPS = (1 << 5),
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_FORMAT = (1 << 6),
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_PROFILE = (1 << 7),
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_PORT_CONFIG = (1 << 8),
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_ROUTE = (1 << 9),
proxy: refactor how PARAM_Props/PropInfo are handled + rename FEATURE_CONTROLS to FEATURE_PROPS + add accessor for the standard spa_param_info (info->params) + hide the low-level params API that nobody uses
2020-05-25 15:33:47 +03:00
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
WP_PROXY_FEATURE_CUSTOM_START = (1 << 16), /*< skip >*/
proxy: refactor the proxy class to hide pipewire API and make things easier
2019-08-22 20:04:39 +03:00
} WpProxyFeatures;
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
/*!
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \brief The minimal feature set for proxies implementing WpPipewireObject.
* This is a subset of \em WP_PIPEWIRE_OBJECT_FEATURES_ALL
* \ingroup wpproxy
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
*/
lib: Use #define instead of 'static const' for constants Fixes build errors when using GCC older than v8.1
2021-06-24 09:24:16 -04:00
#define WP_PIPEWIRE_OBJECT_FEATURES_MINIMAL \
(WP_PROXY_FEATURE_BOUND | WP_PIPEWIRE_OBJECT_FEATURE_INFO)
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
/*!
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \brief The complete common feature set for proxies implementing
* WpPipewireObject. This is a subset of \em WP_OBJECT_FEATURES_ALL
* \ingroup wpproxy
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
*/
lib: Use #define instead of 'static const' for constants Fixes build errors when using GCC older than v8.1
2021-06-24 09:24:16 -04:00
#define WP_PIPEWIRE_OBJECT_FEATURES_ALL \
(WP_PIPEWIRE_OBJECT_FEATURES_MINIMAL | \
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_PROPS | \
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_FORMAT | \
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_PROFILE | \
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_PORT_CONFIG | \
WP_PIPEWIRE_OBJECT_FEATURE_PARAM_ROUTE)
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
docs: api: Replace hotdoc specific commands with Doxygen specific commands
2021-05-13 17:54:58 +03:00
/*!
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
* \brief The WpProxy GType
* \ingroup wpproxy
lib: add extensive API documentation
2020-02-17 15:39:19 +02:00
*/
proxy: add API
2019-06-10 15:07:54 -04:00
#define WP_TYPE_PROXY (wp_proxy_get_type ())
lib: introduce export macros and hide all private symbols
2020-01-16 18:50:07 +02:00
WP_API
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
G_DECLARE_DERIVABLE_TYPE (WpProxy, wp_proxy, WP, PROXY, WpObject)
proxy: add API
2019-06-10 15:07:54 -04:00
struct _WpProxyClass
{
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
WpObjectClass parent_class;
proxy: add destroyed signal
2019-06-18 10:09:40 -04:00
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
/*! \brief the PipeWire type of the interface that is being proxied by
* this class (ex. `PW_TYPE_INTERFACE_Node` for WpNode */
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
const gchar * pw_iface_type;
docs: fix C API documentation to work nicely with doxygen & sphinx
2021-05-21 18:40:43 +03:00
/*! \brief the PipeWire version of the interface that is being
* proxied by this class */
proxy/core: refactor object creation * core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
2020-01-30 17:41:25 +02:00
guint32 pw_iface_version;
proxy: unify common info/params API in the WpProxy base class
2020-01-22 10:34:56 +02:00
/* signals */
proxy: refactor the proxy class to hide pipewire API and make things easier
2019-08-22 20:04:39 +03:00
void (*pw_proxy_created) (WpProxy * self, struct pw_proxy * proxy);
void (*pw_proxy_destroyed) (WpProxy * self);
proxy: add 'bound' signal
2020-03-31 15:04:25 +03:00
void (*bound) (WpProxy * self, guint32 id);
proxy: add error signal
2021-04-28 19:07:43 +03:00
void (*error) (WpProxy * self, int seq, int res, const char *message);
lib: add struct paddings to be able to maintain ABI compatibility Aim for 8 pointers on each struct, wich exceptions: - 12 pointers for already crowded/important ones - 4 pointers for empty ones that are used for proxies; we are unlikely to add any virtual methods on these classes ever
2021-06-08 17:38:14 +03:00
/*< private >*/
WP_PADDING(6)
proxy: add API
2019-06-10 15:07:54 -04:00
};
proxy: replace global-id with bound-id + use the pw_proxy API to find the bound id instead of relying on WpGlobal This has the advantage that it works also for exported objects and for objects that have been created by calling into a remote factory (such as the link-factory), so we can now know the global id of all proxies, not only the ones that have been created by the registry.
2020-01-23 18:50:01 +02:00
WP_API
guint32 wp_proxy_get_bound_id (WpProxy * self);
proxy: add a method to query the interface type
2021-02-04 16:51:25 +02:00
WP_API
const gchar * wp_proxy_get_interface_type (WpProxy * self, guint32 * version);
proxy: unify common info/params API in the WpProxy base class
2020-01-22 10:34:56 +02:00
WP_API
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
struct pw_proxy * wp_proxy_get_pw_proxy (WpProxy * self);
proxy: unify common info/params API in the WpProxy base class
2020-01-22 10:34:56 +02:00
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
/* for subclasses only */
proxy: add set and get control vmethods, and remove them from sub-classes
2020-04-16 15:18:53 -04:00
WP_API
lib: refactor WpProxy This is an attempt to unclutter the API of WpProxy and split functionality into smaller pieces, making it easier to work with. In this new class layout, we have the following classes: - WpObject: base class for everything; handles activating | and deactivating "features" |- WpProxy: base class for anything that wraps a pw_proxy; | handles events from pw_proxy and nothing more |- WpGlobalProxy: handles integration with the registry All the other classes derive from WpGlobalProxy. The reason for separating WpGlobalProxy from WpProxy, though, is that classes such as WpImplNode / WpSpaDevice can also derive from WpProxy now, without interfacing with the registry. All objects that come with an "info" structure and have properties and/or params also implement the WpPipewireObject interface. This provides the API to query properties and get/set params. Essentially, this is implemented by all classes except WpMetadata (pw_metadata does not have info) This interface is implemented on each object separately, using a private "mixin", which is a set of vfunc implementations and helper functions (and macros) to facilitate the implementation of this interface. A notable difference to the old WpProxy is that now features can be deactivated, so it is possible to enable something and later disable it again. This commit disables modules, tests, tools, etc, to avoid growing the patch more, while ensuring that the project compiles.
2020-11-10 19:17:02 +02:00
void wp_proxy_set_pw_proxy (WpProxy * self, struct pw_proxy * proxy);
proxy: add set and get control vmethods, and remove them from sub-classes
2020-04-16 15:18:53 -04:00
proxy: add API
2019-06-10 15:07:54 -04:00
G_END_DECLS
#endif
Reference in a new issue Copy permalink