mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-11-03 09:01:54 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
pipewire/doc/dox/api/index.dox

91 lines
2.4 KiB
Text
Raw Normal View History

doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
/** \page page_api PipeWire API
doc: switch from .md to .dox files and impose some general structure This is an attempt of breaking up the documentation, currently spread across several pages. We're left with a few high-level topics with various things grouped underneath those. Further refinement is necessary, but this can now be done in incremental steps over massive reworks.
2021-05-25 19:55:06 +10:00
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
The PipeWire API consists of several parts:
doc: switch from .md to .dox files and impose some general structure This is an attempt of breaking up the documentation, currently spread across several pages. We're left with a few high-level topics with various things grouped underneath those. Further refinement is necessary, but this can now be done in incremental steps over massive reworks.
2021-05-25 19:55:06 +10:00
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
- The \ref pw_stream for a convenient way to send and receive data streams from/to PipeWire.
- The \ref pw_filter for a convenient way to implement processing filters.
- The \ref api_pw_core to access a PipeWire instance. This API is used
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
by all clients that need to communicate with the \ref page_daemon and provides
the necessary structs to interface with the daemon.
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
- The \ref api_pw_impl is primarily used by the \ref page_daemon itself but also by the
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
\ref page_session_manager and modules/extensions that need to build objects in
the graph.
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
- The \ref api_pw_util containing various utility functions and structures.
- The \ref api_pw_ext for interfacing with certain extension modules.
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
The APIs work through proxy objects, so that calling a method on an object
invokes that same method on the remote side. Marshalling and de-marshalling is
handled transparently by the \ref page_module_protocol_native.
The below graph illustrates this approach:
doc: swap two @ doxygen tags for the backslash ones
2021-09-06 10:47:56 +10:00
\dot
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
digraph API {
compound=true;
node [shape="box"];
rankdir="RL";
subgraph cluster_daemon {
rankdir="TB";
label="PipeWire daemon";
style="dashed";
impl_core [label="Core Impl. Object"];
impl_device [label="Device Impl. Object"];
impl_node [label="Node Impl. Object"];
}
subgraph cluster_client {
rankdir="TB";
label="PipeWire client";
style="dashed";
obj_core [label="Core Object"];
obj_device [label="Device Object"];
obj_node [label="Node Object"];
}
obj_core -> impl_core;
obj_device -> impl_device;
obj_node -> impl_node;
}
doc: swap two @ doxygen tags for the backslash ones
2021-09-06 10:47:56 +10:00
\enddot
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
It is common for clients to use both the \ref api_pw_core and the \ref api_pw_impl
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
and both APIs are provided by the same library.
doc: reorganize files Separate various autogen files from the documentation .dox files. Rename .dox files to match the intended tree structure.
2023-11-18 15:13:05 +02:00
- \subpage page_spa
doc: reorganize some \pages, and fix some group names Move \pages having to do with the API usage to the API section. Better group names for some groups.
2021-10-03 23:30:54 +03:00
- \subpage page_client_impl
- \subpage page_proxy
- \subpage page_streams
- \subpage page_thread_loop
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
\addtogroup api_pw_core Core API
The Core API to access a PipeWire instance. This API is used by all
clients to communicate with the \ref page_daemon.
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
If you are familiar with Wayland implementation, the Core API is
roughly equivalent to libwayland-client.
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
See: \ref page_api
\addtogroup api_pw_impl Implementation API
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
The implementation API provides the tools to build new objects and
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
modules.
doc: document the core/implementation API split a bit better Still missing a proper review of the linked objects, but at least this now explains why those two are split.
2021-08-04 16:33:43 +10:00
If you are familiar with Wayland implementation, the Implementation API is
roughly equivalent to libwayland-server.
doc: switch from .md to .dox files and impose some general structure This is an attempt of breaking up the documentation, currently spread across several pages. We're left with a few high-level topics with various things grouped underneath those. Further refinement is necessary, but this can now be done in incremental steps over massive reworks.
2021-05-25 19:55:06 +10:00
doc: reorganize Doxygen groups/modules to make more sense The Doxygen "Modules" page is not very illuminative, as different parts of the API are mixed together and not all parts are included. Try to address this: Put all parts of the public API to some Doxygen group, usually one group per header file. Use short, systematic names. Make these groups sub-groups of a few top-level groups, roughly corresponding to the different logical parts of the API (core, impl, stream, filter, spa, utilities).
2021-10-02 20:55:53 +03:00
See: \ref page_api
doc: switch from .md to .dox files and impose some general structure This is an attempt of breaking up the documentation, currently spread across several pages. We're left with a few high-level topics with various things grouped underneath those. Further refinement is necessary, but this can now be done in incremental steps over massive reworks.
2021-05-25 19:55:06 +10:00
*/
Reference in a new issue Copy permalink