Introduce new module implementing the status notifier
spec (https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/). The
core dbus logic and spec implementation is from
swaybar (https://github.com/swaywm/sway/tree/master/swaybar/tray), with
rendering stripped out and a switch to tllist. The dbus loop is async and not
re-entrant so the module lock is taken each time we process a message (and when
we process content). To reduce memory usage the icon pixmaps are immutable and
reference counted. So they can be passed between the module and the
particles (through tags) without copying.
Work to be done in future diffs:
1. Tray interactivity/menu support
2. Support KDE search paths for the tray. Can it be implemented with yml
scripting?
Introduce a new icon particle. It follows the icon
spec (https://specifications.freedesktop.org/icon-theme-spec/latest/index.html).
Rendering logic is taken from fuzzel (using nanosvg + libpng), while loading
logic is taken from sway. Standard usage is with `use-tag = false` which expands
the provided string template and then loads the string as the icon name. There
are settings to manually override the base paths, themes, etc. The second usage
which is required for tray support is a special icon tag that transfers raw
pixmaps. With `use-tag = true` it first expands the string, and then uses that
output to find an icon pixmap tag. To reduce memory usage, themes are reference
counted so they can be passed down the configuration stack without having to
load them in multiple times.
For programmability, a fallback particle can be specified if no icon/tag is
found `fallback: ...`. And the new icon pixmap tag can be existence checked in
map conditions using `+{tag_name}`.
Future work to be done in follow up diffs:
1. Icon caching. Currently performs an icon lookup on each instantiation & a
render on each refresh.
2. Theme caching. Changing theme directories results in a new "theme collection"
being created resulting in the possibility of duplicated theme loading.
This patch adds an inheritable option, “font-shaping”, that controls
whether a particle that renders text should enable font-shaping or
not.
The option works similar to the ‘font’ option: one can set it at the
top-level, and it gets inherited down through all modules and to their
particles.
Or, you can set it on a module and it gets inherited to all its
particles, but not to other modules’ particles.
Finally, you can set it on individual particles, in which case it only
applies to them (or “child” particles).
When font-shaping is enabled (the default), the string particle shapes
full text runs using the fcft_rasterize_text_run_utf32() API. In fcft,
this results in HarfBuzz being used to shape the string.
When disabled, the string particle instead uses the simpler
fcft_rasterize_char_utf32() API, which rasterizes individual
characters.
This gives user greater control over the font rendering. One example
is bitmap fonts, which HarfBuzz often doesn’t get right.
Closes#159
New FreeBSD versions have memfd_create but other BSDs don't.
bar/wayland.c:774:15: error: implicit declaration of function 'memfd_create' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
pool_fd = memfd_create("yambar-wayland-shm-buffer-pool", MFD_CLOEXEC);
^
bar/wayland.c:774:62: error: use of undeclared identifier 'MFD_CLOEXEC'
pool_fd = memfd_create("yambar-wayland-shm-buffer-pool", MFD_CLOEXEC);
^
Without this change yambar can't be installed/used without libmpdclient even for
people who do not use MPD. Let's make this optional.
We could put the optional module summary in the module meson.build but we'd have
to move summary() in main meson.build so that they appear in proper order.
Previously, only the date command inside the script was run with
LC_TIME=C.
But there’s no reason to be that conservative; we absolutely do not
want _anything_ in that script to generate locale dependent output.
This enables support for text shaping, and is required to render
e.g. 👩👩👧👧 correctly.
Since text-shaping is a fairly expensive operation, and since many
times the text is unchanged, we cache the last *rendered* string.
That is, we hash the instantiated string, and cache it along with the
text-run from fcft in the *particle* object (i.e. not the exposable).
This means two things:
* we only need to call fcft_text_run_rasterize() once per string
* if the string is the same as last time, we don’t have to call it at
all.
