XPP is a header only C++11 RAII wrapper around X protocol C-language Binding (XCB). Pointers to dynamically allocated memory, such as events and errors are wrapped in std::shared_ptr.
Furthermore, interfaces for connection and resource types are provided to facilitate the creation of custom classes. For convenience, a connection class and several basic resource type classes are readily available.
XPP makes widespread use of the Curiously Recurring Template Pattern (CRTP) to avoid overhead through dynamic dispatch. Hence, most interfaces are implicitly defined.
- Python 2
- GCC >= 4.8 (or Clang >= 3.3, untested)
- libxcb
git clone https://github.com/jrk-/xpp
cd xpp
make
make examples
cd src/examples
for demo in demo_*; do ./${demo}; done
The bindings can be generated by calling make in the top level directory. If
this fails, check the XCBGEN and
PROTODIR variables in
src/proto/Makefile. These need to point to the xcbgen
python package and the xml protocol description respectively.
Once the bindings are generated they can be used by including
src/xpp.hpp. If an extensions is required, it needs to be
included additionally. For example, the RandR extension is available through
proto/randr.hpp, the Damage extension through proto/damage.hpp, etc.
Recent (and working) examples can be found in src/examples.
To compile them, call make examples in the xpp directory or just make in
src/examples.
Requests obey this naming scheme: xpp:: ExtensionName :: RequestName.
Core X protocol:
MapWindow: xcb_map_window{,_checked} -> xpp::x::map_window{,_checked}
InternAtom: xcb_intern_atom{,_checked} -> xpp::x::intern_atom{,_unchecked}
RandR protocol:
SelectInput: xcb_randr_select_input{,_checked} -> xpp::randr::select_input{,_checked}
QueryVersion: xcb_randr_query_version{,_unchecked} -> xpp::randr::query_version{,_unchecked}
All xcb_timestamp_t parameters are alternatively available with a default
value of XCB_TIME_CURRENT_TIME.
Requests which take a list of values as parameters can be used with any STL container by passing in Iterators. Example:
std::string string_example = "example string";
// std::list<char> list_example = { 'a', 'b', 'c' };
// std::map<int, char> map_example = { {0, 'a'}, {1, 'b'}, {2, 'c'} };
xpp::x::change_property_checked(c, XCB_PROP_MODE_REPLACE, window,
atom, XCB_ATOM_STRING, 8,
string_example.begin(), string_example.end());
// list_example.begin(), list_example.end());
// for associative containers the value (std::pair<..>::second_type) will be used
// map_example.begin(), map_example.end());
XCB returns replies only when they are explicitely queried. With XPP this is not necessary anymore, because the operators for accessing the reply are overloaded.
For example, getting the reply for the InternAtom request is as simple as this:
auto reply = xpp::x::intern_atom(connection, true, "MY_ATOM_NAME");
// do some other stuff ..
// latency hiding is still effective, because the call to
// xcb_intern_atom_reply happens but now in operator->()
xcb_atom_t atom = reply->atom;
Primitive types like xcb_window_t, xcb_atom_t, etc. can be accessed either
directly through the overloaded operator->() or via a method which has the
same name as the member. These methods are templated with a default template
type of the native type. Any type which is default constructible from the native
type or a connection and the native type can be specified as template argument.
Examples:
xcb_window_t w1 = reply->member;
xcb_window_t w2 = reply.member(); // default template parameter is xcb_window_t
xpp::window w3 = reply.member<xpp::window>();
Lists (e.g. the result for QueryTree) are accessible through iterators. The
value type is templated, with the default being the native data type.
Example:
auto tree = xpp::x::query_tree(c, window);
// default template type: xcb_window_t
for (auto && child : tree.children()) {
// child has type xcb_window_t
}
// xpp::window is constructible with a connection and xcb_window_t
// other types which are default-constructible with either the value type
// (e.g. xcb_window_t) or a connection & the value type are possible, too
for (auto && child : tree.children<xpp::window>()) {
// child has type xpp::window
}
Caveat: Some requests (in particular GetProperty) return an untyped array of
bytes (void *). To access the desired data type, a template type must be
specified. For constructible types a type trait must be implemented, like so:
struct my_type {
my_type(const xcb_window_t &);
// ..
};
namespace xpp { namespace generic {
struct traits<my_type> {
typedef xcb_atom_t type;
};
}; }; // namespace xpp::generic
XCB offers four different variants of request functions.
-
Error delivered through event queue:
xcb_void_cookie_t xcb_request(...) -
Error can be checked immediately with
xcb_request_check(xcb_connection_t *, xcb_void_cookie_t):xcb_void_cookie_t xcb_request_checked(...)
-
Error can be checked when getting the reply:
xcb_request_reply_t * xcb_request_reply(xcb_connection_t *, xcb_request_cookie_t, xcb_generic_error_t **):xcb_request_cookie_t xcb_request(...) -
Error delivered through event queue:
xcb_request_cookie_t xcb_request_unchecked(...)
For more information on this, refer to xcb-requests (3).
With xpp errors are either thrown as std::shared_ptr<xcb_generic_error_t> or
typed as xpp:: extension ::error:: error_type, e.g. xpp::x::error::value.
The latter are based upon xpp::generic::error (which inherits from
std::runtime_error) and come with a textual error description which is
accessible through the what() method.
For typed errors it is necessary to use a connection class which implements the
appropriate error dispatching. The supplied xpp::connection class already does
this. If no error dispatcher are available (e.g. when used with
xcb_connection_t *), then a simply std::shared_ptr<xcb_generic_error_t>
will be thrown.
Events returned by the event producing methods (wait_for_event,
poll_for_event, etc.) from xpp::core and xpp::connection are encapsulated
as std::shared_ptr<xcb_generic_event_t>.
For additional convenience typed events are available. An event type is based on
xpp::generic::event. The general structure for a typed event is
xpp:: Extension ::event:: EventName
Examples:
xpp::x::event::key_press
xpp::randr::event::notify
xpp::damage::event::notify
Events can be converted from std::shared_ptr<xcb_generic_event_t> to a typed
event by either using an event dispatcher functor (e.g.
xpp::x::event::dispatcher) or by using the event registry described below.
The event registry xpp::event::registry<Connection, Extensions ...> can be
used to connect events and event handlers.
First, a registry object for the desired Connection type and Extensions is
necessary.
Then, arbitrary objects, which implement the xpp::event::sink<..> interface
need to be attached for event handling by calling the attach() method.
It takes two parameters. The first one specifies the priority, in case there are
more than one event handler for this event. Handlers with lower priorities are
called first. The second one is a pointer to an object which implements the
xpp::event::sink<..> interface.
For a detailed example, take a look at this demo.
Interfaces for creating custom types are available.
For every extension a "connection" interface, called
xpp:: ExtensionName ::interface<typename Derived, typename Connection>
is available.
These encapsulate every request for a particular extension. The Derived
template parameter specifies the class which wants to derive from the interface.
The Derived class must provide a method Connection connection();.
Examples:
xpp::x::interface<typename Derived, typename Connection>
xpp::randr::interface<typename Derived, typename Connection>
xpp::damage::interface<typename Derived, typename Connection>
etc.
For a customizable default implementation, take a look at the xpp::connection
class described here.
In addition, interfaces for basic resource types like xcb_window_t,
xcb_atom_t, xcb_gcontext_t, etc. are available.
Again, the naming scheme follows the format
xpp:: ExtensionName :: XidType <typename Derived, typename Connection>
Despite the connection() method described here,
Derived needs to implement a resource() method which returns a xid which
will be passed as parameter to the encapsulated requests.
Examples:
xpp::x::window<typename Derived, typename Connection>
xpp::randr::output<typename Derived, typename Connection>
xpp::render::glyphset<typename Derived, typename Connection>
etc.
xpp::connection<Extensions ...> provides a default
implementation of the core connection methods, the core
X protocol and error handling facilities. In addition, it is implicitly
convertible to xcb_connection_t *, hence it can be used seamlessly with XCB
functions. The connection can be augmented with additional extension methods, by
specifying the desired extensions as template parameters.
Example:
typedef xpp::connection<xpp::randr::extension, xpp::damage::extension> my_connection;
For the basic resource types like Drawable, Window, Pixmap, Atom,
Colormap, Cursor, Font, Fontable and GContext wrapper types exist.
They are named xpp::drawable, xpp::window, etc.
Each is based upon xpp::generic::resource and provides the core X protocol
interface for the encapsulated resource type. If the resource can be acquired
from the X server (e.g. with CreateWindow) then a named constructor is
available (e.g. create_window for xpp::window).
Resources acquired through the named constructors are reference counted. When their lifetime expires, the resource handle will automatically be freed on the server. No call to destroy or free functions is necessary.