|
virtual | ~Xenium () noexcept |
| Destructor. More...
|
|
int32_t | keyRepeatDelay () const noexcept |
| The key repeat delay. More...
|
|
int32_t | keyRepeatRate () const noexcept |
| The key repeat rate. More...
|
|
Xenium::Output | output (const Xenium::OutputId) const noexcept |
| Get a copy of the Output information. More...
|
|
Xenium::PointMm | outputConvertToMm (const Xenium::OutputId, const Xenium::PointPixel &) const noexcept |
| Convert Pixel to Millimeter. More...
|
|
Xenium::SizeMm | outputConvertToMm (const Xenium::OutputId, const Xenium::SizePixel &) const noexcept |
| Convert Pixel to Millimeter. More...
|
|
Xenium::PointPercent | outputConvertToPercent (const Xenium::OutputId, const Xenium::PointPixel &) const noexcept |
| Convert Pixel to a Percentage. More...
|
|
Xenium::SizePercent | outputConvertToPercent (const Xenium::OutputId, const Xenium::SizePixel &) const noexcept |
| Convert Pixel to a Percentage. More...
|
|
Xenium::PointPixel | outputConvertToPixel (const Xenium::OutputId, const Xenium::PointMm &) const noexcept |
| Convert Millimeter to Pixel. More...
|
|
Xenium::PointPixel | outputConvertToPixel (const Xenium::OutputId, const Xenium::PointPercent &) const noexcept |
| Convert Percentage to Pixel. More...
|
|
Xenium::SizePixel | outputConvertToPixel (const Xenium::OutputId, const Xenium::SizeMm &) const noexcept |
| Convert Millimeter to Pixel. More...
|
|
Xenium::SizePixel | outputConvertToPixel (const Xenium::OutputId, const Xenium::SizePercent &) const noexcept |
| Convert Percentage to Pixel. More...
|
|
void | outputOnAdd (Xenium::LambdaOutputId) noexcept |
| Notification of adding an Output device. More...
|
|
void | outputOnChange (Xenium::LambdaOutputId) noexcept |
| Notification that an Output device has changed. More...
|
|
void | outputOnRemove (Xenium::LambdaOutputId) noexcept |
| Notification of removing an Output device. More...
|
|
Xenium::VectorOutputId | outputVector () const noexcept |
| Get a list of the Output Id's. More...
|
|
Xenium::Window * | windowCreate (const Xenium::SizeMm &, const uint32_t, xcb_create_window_value_list_t &, std::error_code &) noexcept |
| Create a window. More...
|
|
Xenium::Window * | windowCreate (const Xenium::SizeMm &, std::error_code &) noexcept |
| Create a window. More...
|
|
Xenium::Window * | windowCreate (const Xenium::SizePercent &, const uint32_t, xcb_create_window_value_list_t &, std::error_code &) noexcept |
| Create a window. More...
|
|
Xenium::Window * | windowCreate (const Xenium::SizePercent &, std::error_code &) noexcept |
| Create a window. More...
|
|
Xenium::Window * | windowCreate (const Xenium::SizePixel &, const uint32_t, xcb_create_window_value_list_t &, std::error_code &) noexcept |
| Create a window. More...
|
|
Xenium::Window * | windowCreate (const Xenium::SizePixel &, std::error_code &) noexcept |
| Create a window. More...
|
|
|
using | Lambda = std::function< void()> |
| A Lambda that has no parameters.
|
|
using | LambdaAxis = std::function< void(const Xenium::PointerAxis &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: PointerAxis and KeyModifier.
|
|
using | LambdaBool = std::function< void(bool)> |
| A Lambda that has a parameter: bool.
|
|
using | LambdaButtonMm = std::function< void(const Xenium::PointerButton &, const Xenium::PointMm &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: PointerButton, PointMm and KeyModifier.
|
|
using | LambdaButtonPercent = std::function< void(const Xenium::PointerButton &, const Xenium::PointPercent &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: PointerButton, PointPercent and KeyModifier.
|
|
using | LambdaButtonPixel = std::function< void(const Xenium::PointerButton &, const Xenium::PointPixel &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: PointerButton, PointPixel and KeyModifier.
|
|
using | LambdaKey = std::function< void(const Xenium::Key &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: Key and KeyModifier.
|
|
using | LambdaPointMm = std::function< void(const Xenium::PointMm &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: PointMm and KeyModifier.
|
|
using | LambdaPointPercent = std::function< void(const Xenium::PointPercent &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: PointPercent and KeyModifier.
|
|
using | LambdaPointPixel = std::function< void(const Xenium::PointPixel &, const Xenium::KeyModifier &)> |
| A Lambda that has parameters: PointPixel and KeyModifier.
|
|
using | LambdaSizeMm = std::function< void(const Xenium::SizeMm &)> |
| A Lambda that has a parameter: SizeMm.
|
|
using | LambdaSizePercent = std::function< void(const Xenium::SizePercent &)> |
| A Lambda that has a parameter: SizePercent.
|
|
using | LambdaSizePixel = std::function< void(const Xenium::SizePixel &)> |
| A Lambda that has a parameter: SizePixel.
|
|
using | LambdaWindowDecorations = std::function< void(Xenium::WindowDecorations)> |
| A Lambda that has a parameter: WindowDecorations.
|
|
using | LambdaWindowMode = std::function< void(Xenium::WindowMode)> |
| A Lambda that has a parameter: WindowMode.
|
|
Refer to Zakero_Xenium.h to learn how to include this library.
The intent of this class is to make creating programs that interface directly with X11 easier. While there are toolkits out there that do this (GTK, Qt, SDL, etc.), they also come with a lot of overhead. This class will abstract much of X11 and provide a simple event driven interface.
As soon as a connection to the X11 server has been established, a thread will be created to move all the communications to the background. This means that there is no "main loop" in the Xenium object to hook into. The benefit to this is that Window contents/graphics will not block event handling.
Refer to How To Use It? for a simple example.
- Window
Using Xenium to connect to a X11 server is just the first step. The next step is to create a Window that can display something. This is done using one of the windowCreate() methods. There are 3 sets of methods:
- Millimeters
- Percent
- Pixels
Why three? The traditional pixels for size has many problems in today's display technology. A resolution of 1024x768 may sound consistent in that you know exactly how many pixels will be used on every display. However, 1024x768 may be OK on some displays, it may be too small on 4k laptop screens. And what about the 8k displays?
The easy answer is to find the maximum resolution and use all of it, or just half for a windowed app. Instead of doing that work, why not just use percentages like 1.00x1.00 or 0.50x0.50 that will work on all display resolutions? That is why Xenium has the SizePercent object.
What about millimeters? Using millimeters gives the developer more confidence that size of an area will be physically consistent across devices. To illustrate this consider defining a 300x150 button. This button may be easily clickable on most monitors but may be too small on a 4k display. Defining a button to be 20mm x 10mm, it will be the same physical size on all monitors.
What's wrong with using DPI?
DPI has become a mess in the computer world and it is resolution, not a size.
- Multi-Threaded Considerations
- The main X11 event loop runs in a dedicated thread. While all the X11 communication is not hindering the application, keep in mind that all event lambdas will be executed by Xenium's internal event loop. This means two things:
- Lambdas that execute for a "long" time will slow down the event loop.
So keep lambdas a simple and as short as possible.
- If the application depends on a value that is updated by an event lambda, that value can change at any time. Consider making a copy of the value before using it.
- Code Structure
Looking at the code for Xenium, you will quickly see that it does not follow traditional Object Oriented design. Instead of having all the XCB data and functions in the Window class, everything is in the Xenium class and the Window only has an ID that is passed to the Xenium class. Yes, this is Data Oriented design. Using Data Oriented design for Xenium has the following benefits:
Threading
Thread execution does not cross object boundaries. This helps maintain a cleaner mental model of "which thread is doing what".
C++ Access Restrictions
Having Window as a inner class of Xenium allows the Window to be able to access Xenium's private members. However, Xenium does not have access to any of Window's private members. Using this access structure, both Xenium and a Window can use the event lambdas. If Window was not an inner class, then one or both of Xenium and Window would have to be friend
s. (friend
by-passes C++ access restrictions, not good)
Performance
Yes, it had to be mentioned. The core of Xenium is the XCB event loop. If the event loop had to load the entire contents of a window just to access a small handful of data for each event, there would a performance hit. With the current design, each event will only load the data it needs. Much faster.
Xenium * zakero::Xenium::connect |
( |
const std::string & |
display, |
|
|
std::error_code & |
error |
|
) |
| |
|
staticnoexcept |
Establish a connection with the X11 server using the provided display
name. If the display
name is empty then the following values will be used to determine which X11 server to connect to:
- DISPLAY
Use the value of this environment variable.
nullptr
The X11 defined default.
If a connection was successful, then a pointer to a new Xenium instance will be returned. This pointer will need to be delete
d by the caller. If there was an error connecting to the X11 server, nullptr
will be returned.
The provided error
will be set to Xenium::Error_None or the reason for the connection failure. An error code of Xenium::Error_Connection_Failed
or Xenium::Error_Invalid_Display_Name
may indicate that there is no X11 server available.
- Note
- A connection to the X11 server must be made before any windows are created.
- Returns
- A pointer to a Xenium instance or a
nullptr
if there was an error.
- Parameters
-
display | The Display Name or ID |
error | The error status |
Xenium * zakero::Xenium::connect |
( |
std::error_code & |
error | ) |
|
|
staticnoexcept |
Establish a connection with the X11 server. The following values will be used to determine which X11 server to connect to:
- DISPLAY
Use the value of this environment variable.
nullptr
The X11 defined default.
If a connection was successful, then a pointer to a new Xenium instance will be returned. This pointer will need to be delete
d by the caller. If there was an error connecting to the X11 server, nullptr
will be returned.
The provided error
will be set to Xenium::Error_None or the reason for the connection failure. An error code of Xenium::Error_Connection_Failed
or Xenium::Error_Invalid_Display_Name
may indicate that there is no X11 server available.
- Note
- A connection to the X11 server must be made before any windows are created.
- Returns
- A pointer to a Xenium instance or a
nullptr
if there was an error.
- Parameters
-