# Libweston

Contents:

- Compositor
  - Compositor API
- Weston config
  - `weston_config_get_section()`
  - `weston_config_section_get_int()`
  - `weston_config_section_get_uint()`
  - `weston_config_section_get_color()`
  - `weston_config_section_get_double()`
  - `weston_config_section_get_string()`
  - `weston_config_section_get_bool()`
  - `weston_config_get_name_from_env()`
  - `weston_config_parse()`
  - `weston_config_next_section()`
  - `weston_config_destroy()`
  - `weston_config_get_binding_modifier()`
- Shell utils
  - `weston_shell_utils_get_default_output()`
  - `weston_shell_utils_get_focused_output()`
  - `weston_shell_utils_subsurfaces_boundingbox()`
  - `weston_shell_utils_center_on_output()`
  - `weston_shell_utils_surface_get_label()`
  - `weston_shell_utils_curtain_create()`
  - `weston_shell_utils_curtain_destroy()`
  - `weston_shell_utils_view_get_layer_position()`
  - `weston_output_set_shell_private()`
  - `weston_output_get_shell_private()`
- Output management
  - Heads
  - Outputs
- Logging/Debugging
  - Weston’s printf
  - Logging context
  - Log scopes
  - Subscribers
  - Timeline points
  - Debug protocol API
  - Weston Log API
  - Logging API
  - Internal logging API
- Debugging with Flight Recorder

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 `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. Additional helper functions are grouped together under Shell utils, to ease out shell development.

## 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.