weston/doc/sphinx/toc/libweston.rst

Libweston
=========

.. toctree::
   :maxdepth: 2
   :caption: Contents:

   libweston/compositor.rst
   libweston/output-management.rst
   libweston/log.rst

`Libweston` is an effort to separate the re-usable parts of Weston into a
library. `Libweston` provides most of the boring and tedious bits of correctly
implementing core Wayland protocols and interfacing with input and output
systems, so that people who just want to write a new "Wayland window manager"
(WM) or a small desktop environment (DE) can focus on the WM part.

Libweston was first introduced in Weston 1.12, and is expected to continue
evolving through many Weston releases before it achieves a stable API and
feature completeness.

`Libweston`'s primary purpose is exporting an API for creating Wayland
compositors. Libweston's secondary purpose is to export the weston_config API
so that third party plugins and helper programs can read :file:`weston.ini` if
they want to. However, these two scopes are orthogonal and independent. At no
point will the compositor functionality use or depend on the weston_config
functionality.

Further work
------------

In current form, `libweston` is an amalgam of various APIs mashed together and
currently it needs a large clean-up and re-organization and possibly, a split
into class-specific files. The documentation only provide the public
API and not the private API used inside `libweston` or other functionality
required in the core internals of the library.

With that in mind we see the following steps needed to achieve that:

- migrate everything that should not reside in the public API (for instance,
  the doxygen **\\internal** command is a clear indication that that symbol
  should not be present in the public API) to private headers.
- if needed be, create class-specific files, like **input** and **output**
  which should tackle specific functionality, and allows to write the
  documentation parts much easier, and provides clarity for `libweston`
  users when they'd read it.
build: Add sphinx/breathe support for generating documentation This is adds basic configuration files for doxygen and for breathe, which is a doxygen-to-sphinx bridge that can document C symbols. Breathe is configured with default project 'weston' and implicitly adds :members: and :undoc-members: to breathe configuration options. This allows a shorter way to call breathe directives without the need specify the project and also to display implicitly all the members, documented or not. A 'docs' run_target to force the docs to be re-built has been added. Initially (the first time the build system is ran) the documentation will automatically be built, but later re-builds will require the use of the 'docs' target. This avoid further delays in building weston but in the same time allows the possiblity to update/improve the documentation bits to those who want that. Signed-off-by: Marius Vlad <marius.vlad@collabora.com> 5 years ago			`Libweston`
			`=========`

			`.. toctree::`
			`:maxdepth: 2`
			`:caption: Contents:`

			`libweston/compositor.rst`
doc: output management sequence diagrams When we were designing the libweston output API, I wrote a design document as a Phabricator wiki page. Phabricator is no longer accessible so that information needs to be migrated to a new place. Here I am converting most of it into libweston Sphinx documentation, particularly pulling in the sequence diagrams I drew. This should help people understand how libweston output configuration works. The diagrams are committed as both MSC source files and rendered PNG files. I did not bother tinkering with the build to run mscgen automatically and then with the CI images to install the tool. The Sphinx configuration need numref explicitly enabled so that figures are automatically numbered and can be referenced by their number rather than their whole caption text(!). The document structure is changed a little better flowing with Output Management being the overview page and the Heads and Outputs being the API pages. First I wrote the struct weston_output and weston_head descriptions in Doxygen comments in libweston.h, but then in the API page that text would have been buried somewhere towards the end of the page. So I put that text in ReST instead where it comes as first on the pages as it should. The doc for the structs only contain a link to the top of the page. Yes, the comment style in libweston.h is a little broken. If I left the asterisk there it would show up as a bullet point in Sphinx. OTOH putting everything from \rst in a single line did not produce anything. Because Sphinx cannot look in two places, the images need to be copied into the build dir too. mscgen: http://www.mcternan.me.uk/mscgen/ Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/25 Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> 5 years ago			`libweston/output-management.rst`
doc/sphinx: Add documentation for the logging/debugging framework This details the logging/debugging framework with the latest changes, making use of the groups added by "weston-log: Start adding documentation" and "libweston/log: Add 'wlog' group". Signed-off-by: Marius Vlad <marius.vlad@collabora.com> 5 years ago			`libweston/log.rst`
build: Add sphinx/breathe support for generating documentation This is adds basic configuration files for doxygen and for breathe, which is a doxygen-to-sphinx bridge that can document C symbols. Breathe is configured with default project 'weston' and implicitly adds :members: and :undoc-members: to breathe configuration options. This allows a shorter way to call breathe directives without the need specify the project and also to display implicitly all the members, documented or not. A 'docs' run_target to force the docs to be re-built has been added. Initially (the first time the build system is ran) the documentation will automatically be built, but later re-builds will require the use of the 'docs' target. This avoid further delays in building weston but in the same time allows the possiblity to update/improve the documentation bits to those who want that. Signed-off-by: Marius Vlad <marius.vlad@collabora.com> 5 years ago
			`Libweston` is an effort to separate the re-usable parts of Weston into a
			library. `Libweston` provides most of the boring and tedious bits of correctly
			`implementing core Wayland protocols and interfacing with input and output`
			`systems, so that people who just want to write a new "Wayland window manager"`
			`(WM) or a small desktop environment (DE) can focus on the WM part.`

			`Libweston was first introduced in Weston 1.12, and is expected to continue`
			`evolving through many Weston releases before it achieves a stable API and`
			`feature completeness.`

			`Libweston`'s primary purpose is exporting an API for creating Wayland
			`compositors. Libweston's secondary purpose is to export the weston_config API`
			so that third party plugins and helper programs can read :file:`weston.ini` if
			`they want to. However, these two scopes are orthogonal and independent. At no`
			`point will the compositor functionality use or depend on the weston_config`
			`functionality.`

			`Further work`
			`------------`

			In current form, `libweston` is an amalgam of various APIs mashed together and
			`currently it needs a large clean-up and re-organization and possibly, a split`
			`into class-specific files. The documentation only provide the public`
			API and not the private API used inside `libweston` or other functionality
			`required in the core internals of the library.`

			`With that in mind we see the following steps needed to achieve that:`

			`- migrate everything that should not reside in the public API (for instance,`
			`the doxygen \\internal command is a clear indication that that symbol`
			`should not be present in the public API) to private headers.`
			`- if needed be, create class-specific files, like input and output`
			`which should tackle specific functionality, and allows to write the`
			documentation parts much easier, and provides clarity for `libweston`
			`users when they'd read it.`