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.
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.
* ‘content’ is a template; the module returns a list of toplevels,
each one instantiated using the content template.
* Each toplevel has 6 tags:
- app-id (string)
- title (string)
- maximized (bool)
- minimized (bool)
- activated (bool)
- fullscreen (bool)
To show the application name and title of the currently active window,
one can do:
- foreign-toplevel:
content:
map:
tag: activated
values:
false: {empty: {}}
true: {string: {text: "{app-id}: {title}"}}
This module exec’s a script (or binary), specified by the ‘path’
attribute in the configuration.
It then reads tags from the script’s stdout.
The format of the output is:
tag|type|value
tag|type|value
<empty line>
I.e. the script writes N tags followed by an empty line. This
constitutes a transaction.
When a new transaction is received, its tags replaces *all* previous
tags.
We subscribe to Sway's 'input' events, and use these to expose input
devices' active XKB layout.
The module is configured by specifying a list of 'identifiers'; these
are the input devices (keyboards, typically), that we'll be
monitoring. All other input devices are ignored.
'content' is a template, and the module will instantiate a dynlist
with a 'content' for each *existing* input found in the 'identifiers'
list.
We also monitor for device 'added' and 'removed' events, and update
our internal list of existing inputs.
This means the user can configure a set of identifiers, and only those
that are actually present will be displayed. If a device that is
listed in the 'identifiers' list is added, it will be displayed. If it
is removed, it will no longer be displayed.
Since this struct only contained function pointers, make all modules
export those functions directly.
The plugin manager now defines a module interface struct, and fills it
it by dlsym:ing the functions that used to be in module_info.
Since this struct only contained function pointers, make all particles
export those functions directly.
The plugin manager now defines a particle interface struct, and fills
it it by dlsym:ing the functions that used to be in particle_info.
