fdo-mirrors/wireplumber
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/wireplumber.git synced 2025-12-21 21:00:03 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
wireplumber/lib/wp/endpoint-link.c

600 lines
18 KiB
C
Raw Normal View History

lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
/* WirePlumber
*
* Copyright © 2020 Collabora Ltd.
* @author George Kiagiadakis <george.kiagiadakis@collabora.com>
*
* SPDX-License-Identifier: MIT
*/
/**
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
* SECTION: endpoint-link
* @title: PipeWire Endpoint Link
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
*/
debug: update all library code to use the new debug system + enable the new log writer on the executables + enable structured logging in the tests
2020-04-14 18:31:17 +03:00
#define G_LOG_DOMAIN "wp-endpoint-link"
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
#include "endpoint-link.h"
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
#include "session.h"
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
#include "debug.h"
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
#include "error.h"
#include "wpenums.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 "private/pipewire-object-mixin.h"
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
#include <pipewire/extensions/session-manager.h>
#include <pipewire/extensions/session-manager/introspect-funcs.h>
enum {
SIGNAL_STATE_CHANGED,
N_SIGNALS,
};
static guint32 signals[N_SIGNALS] = {0};
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
static void wp_endpoint_link_pw_object_mixin_priv_interface_init (
WpPwObjectMixinPrivInterface * iface);
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
/**
* WpEndpointLink:
*
* The #WpEndpointLink class allows accessing the properties and methods of a
* PipeWire endpoint link object (`struct pw_endpoint_link` from the
* session-manager extension).
*
* A #WpEndpointLink is constructed internally when a new endpoint link appears
* on the PipeWire registry and it is made available through the
* #WpObjectManager API.
*/
G_DEFINE_TYPE_WITH_CODE (WpEndpointLink, wp_endpoint_link, WP_TYPE_GLOBAL_PROXY,
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
G_IMPLEMENT_INTERFACE (WP_TYPE_PIPEWIRE_OBJECT,
wp_pw_object_mixin_object_interface_init)
G_IMPLEMENT_INTERFACE (WP_TYPE_PW_OBJECT_MIXIN_PRIV,
wp_endpoint_link_pw_object_mixin_priv_interface_init));
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
static void
wp_endpoint_link_init (WpEndpointLink * self)
{
}
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
static void
wp_endpoint_link_activate_execute_step (WpObject * object,
WpFeatureActivationTransition * transition, guint step,
WpObjectFeatures missing)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +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
switch (step) {
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
case WP_PW_OBJECT_MIXIN_STEP_BIND:
case WP_TRANSITION_STEP_ERROR:
/* base class can handle BIND and ERROR */
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_OBJECT_CLASS (wp_endpoint_link_parent_class)->
activate_execute_step (object, transition, step, missing);
break;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
case WP_PW_OBJECT_MIXIN_STEP_WAIT_INFO:
/* just wait, info will be emitted anyway after binding */
break;
case WP_PW_OBJECT_MIXIN_STEP_CACHE_PARAMS:
wp_pw_object_mixin_cache_params (object, missing);
break;
default:
g_assert_not_reached ();
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: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +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
static void
wp_endpoint_link_deactivate (WpObject * object, WpObjectFeatures features)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_deactivate (object, 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_OBJECT_CLASS (wp_endpoint_link_parent_class)->deactivate (object, features);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
static const struct pw_endpoint_link_events endpoint_link_events = {
PW_VERSION_ENDPOINT_LINK_EVENTS,
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
.info = (HandleEventInfoFunc(endpoint_link)) wp_pw_object_mixin_handle_event_info,
.param = wp_pw_object_mixin_handle_event_param,
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
};
static void
wp_endpoint_link_pw_proxy_created (WpProxy * proxy, struct pw_proxy * pw_proxy)
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_handle_pw_proxy_created (proxy, pw_proxy,
endpoint_link, &endpoint_link_events);
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: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
static void
wp_endpoint_link_class_init (WpEndpointLinkClass * klass)
{
GObjectClass *object_class = (GObjectClass *) klass;
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 *wpobject_class = (WpObjectClass *) klass;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
WpProxyClass *proxy_class = (WpProxyClass *) klass;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
object_class->get_property = wp_pw_object_mixin_get_property;
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
wpobject_class->get_supported_features =
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_get_supported_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
wpobject_class->activate_get_next_step =
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_activate_get_next_step;
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
wpobject_class->activate_execute_step =
wp_endpoint_link_activate_execute_step;
wpobject_class->deactivate = wp_endpoint_link_deactivate;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
proxy_class->pw_iface_type = PW_TYPE_INTERFACE_EndpointLink;
proxy_class->pw_iface_version = PW_VERSION_ENDPOINT_LINK;
proxy_class->pw_proxy_created = wp_endpoint_link_pw_proxy_created;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
proxy_class->pw_proxy_destroyed =
wp_pw_object_mixin_handle_pw_proxy_destroyed;
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
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_class_override_properties (object_class);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
/**
* WpEndpointLink::state-changed:
* @self: the endpoint link
* @old_state: the old state of the link
* @new_state: the new state of the link
* @error: (nullable): the error string if the new state is
* %WP_ENDPOINT_LINK_STATE_ERROR
*
* Emitted when an endpoint link changes state
*/
signals[SIGNAL_STATE_CHANGED] = g_signal_new (
"state-changed", G_TYPE_FROM_CLASS (klass),
G_SIGNAL_RUN_LAST, 0, NULL, NULL, NULL, G_TYPE_NONE, 3,
WP_TYPE_ENDPOINT_LINK_STATE, WP_TYPE_ENDPOINT_LINK_STATE, G_TYPE_STRING);
}
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
static void
wp_endpoint_link_process_info (gpointer instance, gpointer old_info, gpointer i)
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
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
const struct pw_endpoint_link_info *info = i;
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
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
if (info->change_mask & PW_ENDPOINT_LINK_CHANGE_MASK_STATE) {
WpEndpointLinkState old_state = old_info ?
(WpEndpointLinkState) ((struct pw_endpoint_link_info *) old_info)->state
: WP_ENDPOINT_LINK_STATE_ERROR;
g_signal_emit (instance, signals[SIGNAL_STATE_CHANGED], 0,
old_state, info->state, info->error);
}
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
}
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
static gint
wp_endpoint_link_enum_params (gpointer instance, guint32 id,
guint32 start, guint32 num, WpSpaPod *filter)
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
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (instance);
return pw_endpoint_link_enum_params (d->iface, 0, id, start, num,
filter ? wp_spa_pod_get_spa_pod (filter) : NULL);
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
}
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
static gint
wp_endpoint_link_set_param (gpointer instance, guint32 id, guint32 flags,
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
WpSpaPod * param)
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (instance);
return pw_endpoint_link_set_param (d->iface, id, flags,
wp_spa_pod_get_spa_pod (param));
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
}
static void
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_endpoint_link_pw_object_mixin_priv_interface_init (
WpPwObjectMixinPrivInterface * iface)
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
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_priv_interface_info_init (iface,
endpoint_link, ENDPOINT_LINK);
iface->process_info = wp_endpoint_link_process_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
iface->enum_params = wp_endpoint_link_enum_params;
iface->set_param = wp_endpoint_link_set_param;
}
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
/**
* wp_endpoint_link_get_linked_object_ids:
* @self: the endpoint link
* @output_endpoint: (out) (optional): the bound id of the output (source)
* endpoint
* @input_endpoint: (out) (optional): the bound id of the input (sink)
* endpoint
*
* Retrieves the ids of the objects that are linked by this endpoint link
*
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
* Note: Using this method requires %WP_PIPEWIRE_OBJECT_FEATURE_INFO
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
*/
void
wp_endpoint_link_get_linked_object_ids (WpEndpointLink * self,
lib: remove WpEndpointStream API Add all that goes with it.
2021-03-09 13:13:14 -05:00
guint32 * output_endpoint, guint32 * input_endpoint)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
{
g_return_if_fail (WP_IS_ENDPOINT_LINK (self));
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
struct pw_endpoint_link_info *info = d->info;
g_return_if_fail (info);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
if (output_endpoint)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
*output_endpoint = info->output_endpoint_id;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
if (input_endpoint)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
*input_endpoint = info->input_endpoint_id;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
/**
* wp_endpoint_link_get_state:
* @self: the endpoint link
* @error: (out) (optional) (transfer none): the error string if the state is
* %WP_ENDPOINT_LINK_STATE_ERROR
*
* Retrieves the current state of the link
*
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
* Note: Using this method requires %WP_PIPEWIRE_OBJECT_FEATURE_INFO
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
* Returns: the current state of the link
*/
WpEndpointLinkState
wp_endpoint_link_get_state (WpEndpointLink * self, const gchar ** error)
{
g_return_val_if_fail (WP_IS_ENDPOINT_LINK (self), WP_ENDPOINT_LINK_STATE_ERROR);
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
struct pw_endpoint_link_info *info = d->info;
g_return_val_if_fail (info, WP_ENDPOINT_LINK_STATE_ERROR);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
if (error)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
*error = info->error;
return (WpEndpointLinkState) info->state;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
/**
* wp_endpoint_link_request_state:
* @self: the endpoint link
* @target: the desired target state of the link
*
* Requests a state change on the link
*
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
* Note: Using this method requires %WP_PROXY_FEATURE_BOUND
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
*/
void
wp_endpoint_link_request_state (WpEndpointLink * self,
WpEndpointLinkState target)
{
g_return_if_fail (WP_IS_ENDPOINT_LINK (self));
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
g_return_if_fail (d->iface);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
pw_endpoint_link_request_state (d->iface,
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
(enum pw_endpoint_link_state) target);
}
/* WpImplEndpointLink */
enum {
IMPL_PROP_0,
IMPL_PROP_ITEM,
};
struct _WpImplEndpointLink
{
WpEndpointLink parent;
struct spa_interface iface;
struct pw_endpoint_link_info info;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpProperties *immutable_props;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
WpSiLink *item;
};
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
static void wp_endpoint_link_impl_pw_object_mixin_priv_interface_init (
WpPwObjectMixinPrivInterface * iface);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
G_DEFINE_TYPE_WITH_CODE (WpImplEndpointLink, wp_impl_endpoint_link, WP_TYPE_ENDPOINT_LINK,
G_IMPLEMENT_INTERFACE (WP_TYPE_PW_OBJECT_MIXIN_PRIV,
wp_endpoint_link_impl_pw_object_mixin_priv_interface_init))
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
static void
on_item_activated (WpSessionItem * item, GAsyncResult * res, gpointer data)
{
WpImplEndpointLink *self = WP_IMPL_ENDPOINT_LINK (data);
g_autoptr (GError) error = NULL;
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
if (!wp_object_activate_finish (WP_OBJECT (item), res, &error)) {
debug: update all library code to use the new debug system + enable the new log writer on the executables + enable structured logging in the tests
2020-04-14 18:31:17 +03:00
wp_message_object (self, "failed to activate link: %s", error->message);
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
self->info.error = g_strdup (error->message);
/* on_si_link_flags_changed() will be called right after we return,
taking care of the rest... */
}
}
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
static int
impl_request_state (void *object, enum pw_endpoint_link_state state)
{
WpImplEndpointLink *self = WP_IMPL_ENDPOINT_LINK (object);
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
int ret = 0;
if (state == self->info.state)
return ret;
switch (state) {
case PW_ENDPOINT_LINK_STATE_ACTIVE:
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
wp_object_activate (WP_OBJECT (self->item),
WP_SESSION_ITEM_FEATURE_ACTIVE, NULL,
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
(GAsyncReadyCallback) on_item_activated, self);
break;
case PW_ENDPOINT_LINK_STATE_INACTIVE:
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
wp_object_deactivate (WP_OBJECT (self->item),
WP_SESSION_ITEM_FEATURE_ACTIVE);
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
break;
default:
ret = -EINVAL;
break;
}
return ret;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
static const struct pw_endpoint_link_methods impl_endpoint_link = {
PW_VERSION_ENDPOINT_LINK_METHODS,
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
.add_listener =
(ImplAddListenerFunc(endpoint_link)) wp_pw_object_mixin_impl_add_listener,
.subscribe_params = wp_pw_object_mixin_impl_subscribe_params,
.enum_params = wp_pw_object_mixin_impl_enum_params,
.set_param = wp_pw_object_mixin_impl_set_param,
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
.request_state = impl_request_state,
};
static void
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_impl_endpoint_link_init (WpImplEndpointLink * self)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
self->iface = SPA_INTERFACE_INIT (
PW_TYPE_INTERFACE_EndpointLink,
PW_VERSION_ENDPOINT_LINK,
&impl_endpoint_link, self);
d->info = &self->info;
d->iface = &self->iface;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
static void
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
populate_properties (WpImplEndpointLink * self)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpPwObjectMixinData *d = wp_pw_object_mixin_get_data (self);
g_clear_pointer (&d->properties, wp_properties_unref);
d->properties = wp_si_link_get_properties (self->item);
if (!d->properties)
d->properties = wp_properties_new_empty ();
d->properties = wp_properties_ensure_unique_owner (d->properties);
wp_properties_update (d->properties, self->immutable_props);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
self->info.props = (struct spa_dict *) wp_properties_peek_dict (d->properties);
}
static void
on_si_link_properties_changed (WpSiLink * item, WpImplEndpointLink * self)
{
populate_properties (self);
wp_pw_object_mixin_notify_info (self, PW_ENDPOINT_LINK_CHANGE_MASK_PROPS);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
static void
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
on_si_link_features_changed (WpSiLink * item, GParamSpec * param,
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
WpImplEndpointLink * self)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
{
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
enum pw_endpoint_link_state old_state = self->info.state;
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
guint features = wp_object_get_active_features (WP_OBJECT (item));
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
if (features & WP_SESSION_ITEM_FEATURE_ACTIVE)
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
self->info.state = PW_ENDPOINT_LINK_STATE_ACTIVE;
else
self->info.state = PW_ENDPOINT_LINK_STATE_INACTIVE;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
if (old_state != self->info.state) {
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_pw_object_mixin_notify_info (self, PW_ENDPOINT_LINK_CHANGE_MASK_STATE);
endpoint-link: use the session item's activation state to implement the link's state
2020-04-09 19:27:33 +03:00
g_signal_emit (self, signals[SIGNAL_STATE_CHANGED], 0,
old_state, self->info.state, self->info.error);
}
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
static void
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_impl_endpoint_link_constructed (GObject * object)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
{
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
WpImplEndpointLink *self = WP_IMPL_ENDPOINT_LINK (object);
g_autoptr (GVariant) info = NULL;
g_autoptr (GVariantIter) immutable_props = NULL;
const gchar *key, *value;
si-interfaces: make WpSiLink work with WpSiPortInfo instead of WpSiEndpoint
2021-03-23 13:35:52 -04:00
g_autoptr (WpSiPortInfo) si_out = NULL;
g_autoptr (WpSiPortInfo) si_in = NULL;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
self->info.version = PW_VERSION_ENDPOINT_LINK_INFO;
self->info.error = NULL;
self->info.params = NULL;
self->info.n_params = 0;
/* get info from the interface */
info = wp_si_link_get_registration_info (self->item);
g_variant_get (info, "a{ss}", &immutable_props);
/* get the current state */
self->info.state =
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
(wp_object_get_active_features (WP_OBJECT (self->item))
& WP_SESSION_ITEM_FEATURE_ACTIVE)
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
? PW_ENDPOINT_LINK_STATE_ACTIVE
: PW_ENDPOINT_LINK_STATE_INACTIVE;
lib: remove WpEndpointStream API Add all that goes with it.
2021-03-09 13:13:14 -05:00
/* associate with the session and the endpoints */
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
self->info.session_id = wp_session_item_get_associated_proxy_id (
WP_SESSION_ITEM (self->item), WP_TYPE_SESSION);
si-interfaces: make WpSiLink work with WpSiPortInfo instead of WpSiEndpoint
2021-03-23 13:35:52 -04:00
si_out = wp_si_link_get_out_item (self->item);
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
self->info.output_endpoint_id = wp_session_item_get_associated_proxy_id (
m-si-standard-link: use a weak reference for in and out endpoints Allows checking if the endpoints are still valid before releasing the acquisition. Sometimes the endpoints are destroyed before the link, and releasing acquisition is not needed. There is no way to check that with raw pointers.
2021-03-25 15:34:24 -04:00
WP_SESSION_ITEM (si_out), WP_TYPE_ENDPOINT);
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
si-interfaces: make WpSiLink work with WpSiPortInfo instead of WpSiEndpoint
2021-03-23 13:35:52 -04:00
si_in = wp_si_link_get_in_item (self->item);
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
self->info.input_endpoint_id = wp_session_item_get_associated_proxy_id (
m-si-standard-link: use a weak reference for in and out endpoints Allows checking if the endpoints are still valid before releasing the acquisition. Sometimes the endpoints are destroyed before the link, and releasing acquisition is not needed. There is no way to check that with raw pointers.
2021-03-25 15:34:24 -04:00
WP_SESSION_ITEM (si_in), WP_TYPE_ENDPOINT);
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
/* construct export properties (these will come back through
the registry and appear in wp_proxy_get_global_properties) */
self->immutable_props = wp_properties_new_empty ();
wp_properties_setf (self->immutable_props,
PW_KEY_SESSION_ID, "%d", self->info.session_id);
wp_properties_setf (self->immutable_props,
PW_KEY_ENDPOINT_LINK_OUTPUT_ENDPOINT, "%d", self->info.output_endpoint_id);
wp_properties_setf (self->immutable_props,
PW_KEY_ENDPOINT_LINK_INPUT_ENDPOINT, "%d", self->info.input_endpoint_id);
/* populate immutable (global) properties */
while (g_variant_iter_next (immutable_props, "{&s&s}", &key, &value))
wp_properties_set (self->immutable_props, key, value);
/* populate standard properties */
populate_properties (self);
/* subscribe to changes */
g_signal_connect_object (self->item, "link-properties-changed",
G_CALLBACK (on_si_link_properties_changed), self, 0);
session-item: refactor and inherit from WpObject This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED features, so _activate and _export APIs have been removed. Modules and unit tests have also been updated.
2021-03-17 14:52:41 -04:00
g_signal_connect_object (self->item, "notify::active-features",
G_CALLBACK (on_si_link_features_changed), self, 0);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_object_update_features (WP_OBJECT (self),
WP_PIPEWIRE_OBJECT_FEATURE_INFO, 0);
G_OBJECT_CLASS (wp_impl_endpoint_link_parent_class)->constructed (object);
}
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
static void
wp_impl_endpoint_link_dispose (GObject * object)
{
WpImplEndpointLink *self = WP_IMPL_ENDPOINT_LINK (object);
g_clear_pointer (&self->immutable_props, wp_properties_unref);
g_clear_pointer (&self->info.error, g_free);
wp_object_update_features (WP_OBJECT (self), 0,
WP_PIPEWIRE_OBJECT_FEATURE_INFO);
G_OBJECT_CLASS (wp_impl_endpoint_link_parent_class)->dispose (object);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
}
static void
wp_impl_endpoint_link_set_property (GObject * object, guint property_id,
const GValue * value, GParamSpec * pspec)
{
WpImplEndpointLink *self = WP_IMPL_ENDPOINT_LINK (object);
switch (property_id) {
case IMPL_PROP_ITEM:
self->item = g_value_get_object (value);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
static void
wp_impl_endpoint_link_get_property (GObject * object, guint property_id,
GValue * value, GParamSpec * pspec)
{
WpImplEndpointLink *self = WP_IMPL_ENDPOINT_LINK (object);
switch (property_id) {
case IMPL_PROP_ITEM:
g_value_set_object (value, self->item);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
static void
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_impl_endpoint_link_activate_execute_step (WpObject * object,
WpFeatureActivationTransition * transition, guint step,
WpObjectFeatures missing)
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +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
WpImplEndpointLink *self = WP_IMPL_ENDPOINT_LINK (object);
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +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
switch (step) {
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
case WP_PW_OBJECT_MIXIN_STEP_BIND: {
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_autoptr (WpCore) core = wp_object_get_core (object);
struct pw_core *pw_core = wp_core_get_pw_core (core);
/* no pw_core -> we are not connected */
if (!pw_core) {
wp_transition_return_error (WP_TRANSITION (transition), g_error_new (
WP_DOMAIN_LIBRARY, WP_LIBRARY_ERROR_OPERATION_FAILED,
"The WirePlumber core is not connected; "
"object cannot be exported to PipeWire"));
return;
}
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +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
/* bind */
wp_proxy_set_pw_proxy (WP_PROXY (self), pw_core_export (pw_core,
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
PW_TYPE_INTERFACE_EndpointLink,
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
wp_properties_peek_dict (self->immutable_props),
&self->iface, 0));
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
break;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +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
default:
WP_OBJECT_CLASS (wp_impl_endpoint_link_parent_class)->
activate_execute_step (object, transition, step, missing);
break;
}
}
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
static void
wp_impl_endpoint_link_class_init (WpImplEndpointLinkClass * klass)
{
GObjectClass *object_class = (GObjectClass *) klass;
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 *wpobject_class = (WpObjectClass *) klass;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
WpProxyClass *proxy_class = (WpProxyClass *) klass;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
object_class->constructed = wp_impl_endpoint_link_constructed;
object_class->dispose = wp_impl_endpoint_link_dispose;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
object_class->set_property = wp_impl_endpoint_link_set_property;
object_class->get_property = wp_impl_endpoint_link_get_property;
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
wpobject_class->activate_execute_step =
wp_impl_endpoint_link_activate_execute_step;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
proxy_class->pw_proxy_created = NULL;
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
proxy_class->pw_proxy_destroyed = NULL;
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
g_object_class_install_property (object_class, IMPL_PROP_ITEM,
g_param_spec_object ("item", "item", "item", WP_TYPE_SI_LINK,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY | G_PARAM_STATIC_STRINGS));
}
pw-object-mixin: refactor, implement param caching and features for impl objects Now the WpPipewireObject interface is directly implemented by the mixin and there is another interface that users of the mixin must implement in order for the mixin to work proprely. A lot of manual stuff that proxy classes had to do before are now in the mixin. Also most of the data that would normally reside in Private structures is now in the mixin data structure (stored as qdata on the object). This is achieving the best amount of code reuse so far. For impl objects (WpImpl*) there are also default implementations of the standard pipewire object methods and the INFO & PARAM_* features are more coherently enabled during the whole lifetime of these objects.
2020-11-25 14:02:33 +02:00
#define pw_endpoint_link_emit(hooks,method,version,...) \
spa_hook_list_call_simple(hooks, struct pw_endpoint_link_events, \
method, version, ##__VA_ARGS__)
static void
wp_impl_endpoint_link_emit_info (struct spa_hook_list * hooks, gconstpointer info)
{
pw_endpoint_link_emit (hooks, info, 0, info);
}
static void
wp_impl_endpoint_link_emit_param (struct spa_hook_list * hooks, int seq,
guint32 id, guint32 index, guint32 next, const struct spa_pod *param)
{
pw_endpoint_link_emit (hooks, param, 0, seq, id, index, next, param);
}
static void
wp_endpoint_link_impl_pw_object_mixin_priv_interface_init (
WpPwObjectMixinPrivInterface * iface)
{
iface->flags |= WP_PW_OBJECT_MIXIN_PRIV_NO_PARAM_CACHE;
iface->enum_params = NULL;
iface->set_param = NULL;
iface->emit_info = wp_impl_endpoint_link_emit_info;
iface->emit_param = wp_impl_endpoint_link_emit_param;
}
lib: implement proxy & impl for PW_TYPE_INTERFACE_EndpointLink
2020-03-31 19:26:56 +03:00
WpImplEndpointLink *
wp_impl_endpoint_link_new (WpCore * core, WpSiLink * item)
{
g_return_val_if_fail (WP_IS_CORE (core), NULL);
return g_object_new (WP_TYPE_IMPL_ENDPOINT_LINK,
"core", core,
"item", item,
NULL);
}
Reference in a new issue Copy permalink