Wayland++  0.2.8
C++ Bindings for Wayland
README.md
1 # Introduction
2 
3 Wayland is an object oriented display protocol, which features request
4 and events. Requests can be seen as method calls on certain objects,
5 whereas events can be seen as signals of an object. This makes the
6 Wayland protocol a perfect candidate for a C++ binding.
7 
8 The goal of this library is to create such a C++ binding for Wayland
9 using the most modern C++ technology currently available, providing
10 an easy to use C++ API to Wayland.
11 
12 # Requirements
13 
14 To build this library, a recent version of cmake is required. Furthermore,
15 a recent C++ Compiler with C++11 support, such as GCC or clang, is required.
16 Also, pugixml is required to build the XML protocol scanner. Apart from the
17 Wayland libraries, there are no further library dependencies.
18 
19 The documentation is autogenerated using Doxygen, therefore doxygen as
20 well as graphviz is required.
21 
22 # Building
23 
24 ## Library
25 
26 To build the library, `cmake ..` needs to executed in a newly created
27 `build` directory in the root directory of the repository, followed
28 by a `make`. After that, `make install` will install the library.
29 
30 There are several CMake variables that can be set in order to
31 customise the build and install process:
32 
33 CMake Variable | Effect
34 --------------------------- | ------
35 `CMAKE_CXX_COMPILER` | C++ compiler to use
36 `CMAKE_CXX_FLAGS` | Additional flags for the C++ compiler
37 `CMAKE_INSTALL_PREFIX` | Prefix folder, under which everything is installed
38 `CMAKE_INSTALL_LIBDIR` | Library folder relative to the prefix
39 `CMAKE_INSTALL_INCLUDEDIR` | Header folder relative to the prefix
40 `CMAKE_INSTALL_BINDIR` | Binary folder relative to the prefix
41 `CMAKE_INSTALL_DATAROOTDIR` | Shared folder relative to the prefix
42 `CMAKE_INSTALL_DOCDIR` | Dcoumentation folder relative to the prefix
43 `CMAKE_INSTALL_MANDIR` | Manpage folder relative to the prefix
44 `BUILD_SCANNER` | Whether to build the scanner
45 `BUILD_LIBRARIES` | Whether to build the libraries
46 `BUILD_DOCUMENTATION` | Whether to build the documentation
47 `BUILD_EXAMPLES` | Whether to build the examples
48 
49 The installation root can also be changed using the environment variable
50 `DESTDIR` when using `make install`.
51 
52 ## Documentation
53 
54 If the requirements are met, the documentation will normally be built
55 automatically. HTML pages, LaTeX source files as well as manpages are generated.
56 
57 To build the documentation manually, `doxygen` needs to be executed
58 in the root directory of the repository. The resulting documentation
59 can then be found in the `doc` directory. The required Doxyfile is
60 available after the library has been built. The documentaion is also
61 online availabe [here](https://nilsbrause.github.io/waylandpp_docs/).
62 
63 ## Example programs
64 
65 To build the example programs the `BUILD_EXAMPLES` option needs to be enabled
66 during the build. The resulting binaries will be put under the `example`
67 directory inside the build directory. They can be run directly without
68 installing the library first.
69 
70 To build the example programs manually, `make` can executed in
71 the example directory after the library has been built and installed.
72 
73 # Usage
74 
75 In the following, it is assumed that the reader is familiar with
76 basic Wayland concepts and at least version 11 of the C++
77 programming language.
78 
79 Each interface is represented by a class. E.g. the `wl_registry`
80 interface is represented by the `registry_t` class.
81 
82 An instance of a class is a wrapper for a Wayland object (a `wl_proxy`
83 pointer). If a copy is made of a particualr instance, both instances
84 refer to the same Wayland object. The underlying Wayland object is
85 destroyed once there are no copies of this object left. Only a few
86 classes are non-copyable, namely `display_t` and `egl_window_t`.
87 There are also special rules for proxy wrappers and the use of
88 foreigen objects. Refer to the documentation for more details.
89 
90 A request to an object of a specific interface corresponds to a method
91 in this class. E.g. to marshal the `create_pool` request on an
92 `wl_shm` interface, the `create_pool()` method of an instance of
93 `shm_t` has to be called:
94 
95  shm_t shm;
96  int fd;
97  int32_t size;
98  // ... insert the initialisation of the above here ...
99  shm_pool_t shm_pool = shm.create_pool(fd, size);
100 
101 Some methods return newly created instances of other classes. In this
102 example an instance of the class `shm_pool_t` is returned.
103 
104 Events are implemented using function objects. To react to an event, a
105 function object with the correct signature has to be assigned to
106 it. These can not only be static functions, but also member functions
107 or closures. E.g. to react to global events from the registry using a
108 lambda expression, one could write:
109 
110  registry.on_global() = [] (uint32_t name, std::string interface,
111  uint32_t version)
112  { std::cout << interface << " v" << version << std::endl; };
113 
114 An example for using member functions can be found in
115 example/opengles.cpp or example/shm.cpp.
116 
117 The Wayland protocol uses arrays in some of its events and requests.
118 Since these arrays can have arbitrary content, they are not directly
119 mapped to a std::vector. Instead there is a new type array_t, which
120 can converted to and from a std::vectory with an user specified type.
121 For example:
122 
123  keyboard.on_enter() = [] (uint32_t serial, surface_t surface,
124  array_t keys)
125  { std::vector<uint32_t> vec = keys; };
126 
127 To compile code that using this library, pkg-config can be used to
128 take care of the compiler flags. Assuming the source file is called
129 `foo.cpp` and the executable shall be called `foo` type:
130 
131  $ c++ -c foo.cpp `pkg-config --cflags wayland-client++` -o foo.o
132  $ c++ foo.o `pkg-config --libs wayland-client++` -o foo
133 
134 If the library and headers are installed in the default search paths
135 of the compiler, the linker flag `-lwayland-client++` can also
136 directly be specified on the command line.
137 
138 If the Wayland cursor classes and/or EGL is used, the corresponding
139 libreries `wayland-cursor++` and/or `wayland-egl++` need to be linked
140 in as well. If any extension protocols such as xdg-shell are used,
141 the library `wayland-client-extra++` should be linked in as well.
142 
143 Further examples can be found in the examples/Makefile.