Twclient quick reference ¶
Client data structures ¶
tw_globals: the global structure that fits the need of an wayland client. It contains things like
Inputs: We only have one input per client, this would be connect to one seat, input will handle
tw_event_queue: introduced originally for
tw_shellto handle system generated events like time lapse and wayland protocol events. Very much like
wl_event_loop, which is not available in clients.
tw_event: this leads to another interface for use to create its own event and watch the event. It didn’t go as far as the
wl_protocolswhere you create custom protocols and have handlers for them.
tw_shm_pool: the allocator for shared buffers, binds to
tw_appsurf: it binds to an
wl_surfacefor different roles(protocols). The surface has it implementation of buffer and input events, it has the data but no actual methods to interact with it.
tw_appsurfwas first created for distinguishing background surface and panel surface. So in a sense, Right now it is used for any kind of single surface app. Note that:
tw_appsurf, it has it’s own
It also has input-events, to generate the a new frame.
tw_appsurfis designed to work with different proxies,
taiwins_ui(this is taiwins specific, drawn in UI layer),
xdg_shell_surfaceshould all work, it is an wrap around
wl_surfaceand provides convenient methods for commiting surface and do a new frame.
tw_appsurf_event_filter. But you know not everyting relates to a surface is about frame, would it be able to update something without drawing a new frame? This is why we have an event filter, you can instal the filter to a surface, it runs before the
tw_appsurf.frameand it can optionally skip the
Example of UI implementation ¶
You can implement a
for your needs using
are already predefined implementatin you can take advantage of.
background: background is picture reading and posting, it could be implemented as animation, by calling a frame.
nuklear_backend: this GUI library is implemented with OpenGL or cairo, it implements a
tw_appsurflike a sub class, then use it users can use simply
embeded_surface: This is one that complicates the implementation. It does not have its own data, but also need a frame. The frame is triggered by events.
frame vs other event. ¶
has a central
callback to deal with all events,
structure for what is available, note that those are the
common events. You may implement your specific event through
If you do animations, in wayland, you need to call the
in the next done event.
request a draw call. Optionally, when you call
, you can
specify it is animated.
NUKLEAR backend using Wayland ¶
We implement a cairo and EGL based nuklear renderer for
, user can
to work with
. Then you would be able to use all the nuklear functions in the frame
NUKLEAR pipeline ¶
The nuklear backend does all the heavy job of implementing all the ui forms that
we need for GUI code and you can implement different backend for it. Backend
implementation boils down to take draw command from
and draw basic
geometry, text and image.
nk_commandthough functions like
if you decide to write a CPU backend, then you have to draw based on those command, uses for example (Cairo), remember to use the double buffer(required for wayland).
if you use GPU backend, there is an additional helper function called
nk_convert, which converts the command into vertex buffer, element based on layout you specified.
New Font and image ¶
nk_wl_*_backendimplements a resource management, to load font and image, call
name conversion ¶
CREATE and DESTROY ¶
, for exemple,
, we are getting a pointer then free the pointer in the
is usually not visible, declared in header, defined in source
code. Good example is
, since there could be only one
implementation of it.
INIT and END ¶
In this case, user has the control over the memory, but the interface controls
the heap if any, after calling
, the struct should returns to the init
INIT and RELEASE ¶
Same as above.