This way, we'll actually return our error code to the parent
process if anything goes wrong during the initial stages, instead
of successfully exiting in the parent.
This lets us finally completely get rid of the infrastructure
that boilerplate.h and boilerplate.c used to have for managing
the popup surface and its callbacks.
This type is now responsible for keeping track of
the seat's name and capabilities. An array of available
seats is stored by the registry, which allows you to
find a desired seat by its name.
Now, instead of processing offerred mime types as they
appear, we will collect them into a single buffer inside
struct offer, and then analyze the whole thing when it's
ready.
This way, in the future it'd be possible to handle the case
where we see multiple offers and don't know in adnvance which
ones are the ones we need, and which we should ignore.
This is the first in a series of commits moving parts of logic
that was previously implemented in wl-copy/wl-paste into separate
files, with separate types (structures) that encapsulate, to a
certain degree, the implementation details of a type, somewhat
OOP style.
It's getting increasingly more structured and less boilerplaity,
and this trend is only going to continue. It still remains an internal
static library, at least for now.
We used not to care about this and just make everything
externally visible. Now we switch to a different convention
where everything is static by default unless it needs to be
externally visible.
This largely reverts commits 3eac589774
and cd8cb31e61.
Now that wlroots-based compositors implement the wlr-data-control
protocol, there's no need to use the popup surface hack when running
under them, which means wlr-layer-shell does not actually get used.
While it is possible that a compositor supports wlr-layer-shell but
not wlr-data-control, it is unlikely enough by this point. Furthermore,
wl-clipboard is now used widely enough for niche compositors to consider
implmenting a protocol to make wl-clipboard work better rather than the
other way around. In other words, if your compositor implements
wlr-layer-shell but not wlr-data-control and you would like wl-clipboard
to work well under your compositor, please implement wlr-data-control
in your compositor so that we can avoid relying on hacks.
Closes https://github.com/bugaevc/wl-clipboard/issues/24
