'-' is a valid character for tags.
Commit 03e1c7d (module/network: Add link stats, 2022-04-30) introduced
two new tags for the network module: `ul-speed` and `dl-speed`. These
use the `-` character, that was previously never used in any tag.
We had two options: either change those tags to use `_` instead, or just
accept `-`s as a valid character. Going forward, I can see many people
deciding to name their tags with `-` instead of `_`, so I believe it is
better to just accept it once and for all.
Note that `-` cannot be used as the first character of a tag (e.g.
`-tag1`) since the `-` has a special meaning in `.yml` files. I don't
believe this will happen often, however, and should be easy to both
detect and correct if it does.
A condition is formed by:
<tag> <op> <value>
<tag> is the normal yambar tag. <op> is one of '==', '!=', '<', '<=', '>', or
'>='. <value> is what you wish to compare it to.
'boolean' tags must be used directly. They falsehood is matched with '~':
<tag>
~<tag>
Finally, to match an empty string, one must use ' "" ':
<tag> <op> ""
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
First, apply max-len to the converted wide character string, instead
of the UTF-8 string. This is better, and more correct, since UTF-8 is
multibyte, and applying max-len to that results in strings _shorter_
than max-len.
Second, use HORIZONTAL ELLIPSIS (…) instead of three regular
periods (...) as truncation character. This “saves” 2 characters.
To be able to do this, the conversion to a wide character, and glyph
rasterization is now done when the exposable is instantiated, instead
of in begin_expose().
Closes#73
One can now bind the left/middle/right mouse buttons to on-click. In
fact, you can have all three buttons bound to different handlers for
the same particle. The new syntax is
on-click:
left: <command>
middle: <command>
right: <command>
Leaving one out is the same thing as not mapping it at
all. Furthermore,
on-click: <command>
is still valid, and is a shorthand for
on-click:
left: <commsnd>
a5bbf0b769 introduced text-run
shaping.
Do avoid having to re-shape non-changing strings every time the bar is
refreshed, the *particle* (i.e. not the exposable) caches the last
shaped text-run.
Then, in expose(), it then assumes that that cached text-run is
the *same* text-run as returned from begin_expose().
This is true in most cases, but *not* when a single particle is
re-used to instantiate multiple exposables, as is commonly done by
modules generating dynlists. For example, the i3/sway module.
This fixes it, by making the cache growable, and by adding a “lock” to
each cache entry.
The lock is set in begin_expose(), to indicate that this particular
cache entry is needed in expose().
If we can’t find a matching cache entry, we first try to find a free
“slot” by searching for either unused, or used-but-not-locked cache
entries.
If that fails, we grow the cache and add a new entry.
In expose(), we unset the lock.
Closes#47
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.
The progress-bar took *all* particle elements into account when
calculating the (relative) mouse position on mouse events.
This is wrong, since only the progress bar (that is, the empty and
filled cells) should be used. Not the start/end elements.
We now also pass the mouse event through to the start/end elements.
All decoration, particle and module interfaces now takes a
pixman_image_t parameter, and all drawing is done using pixman APIs.
The wayland/xcb backends implement a new interface functions,
get_pixman_image(), that should return a pixman image instance that is
suitable for rendering.
In the wayland backend, the image uses the same backing data as the
cairo surface.
In the XCB backend, we create a new image each time, and then blit it
to the cairo surface at commit time.
