Zathura can use include directive to gather configuration from multiple
files, make use of that for less intrusive theming changes. Now only
needs to append include directive in main configuration file and the
colorscheme can just be put into a completely separate file.
dunst theming now uses the newly introduced drop-in files for dunst
(v1.8.0) which allow less intrusive theming. Now simply drops a new
colorscheme file in the right location instead of meddling with the main
configuration file.
Polybar restarting is now done through its provided ipc interface,
instead of relying on a hardcoded script on the system.
Previously, the system needed access to a `polybar-launch` script.
Now, it invokes the `polybar-msg` command which is provided by polybar
itself.
It is important that polybar has ipc enabled in its configuration for
the restart to work.
Alacritty processor will now add the colorscheme via include statement
in the original configuration file instead of adding the theme directly
to the file.
Processor will now automatically create the necessary directory to put
the css stylesheet into if the directory does not exist yet,
instead of failing to apply the theme.
Will print debug info to libnotify but additionally print everything to
stdout now.
This should help when explicitly invoking styler from a shell (by
setting `export STYLER_DEBUG=2` or `=3`) and either reading the output
there or redirecting it to a file.
If `send-notify` is recognized as valid command, the dbg_msg function
will send it there instead of printing it to stdout. The urgency of the
message corresponds with low/normal/critical to the debug levels
info/warn/error.
Takes a prepared stylesheet template, inserts the values into it and
puts it into fixed qutebrowser stylesheet directory, calling qutebrowser
to set it automatically.
Much of this is hardcoded and not applicable to different setups!
Added simple support for dunst files. Since files can, similar to
alacritty, not be included in dunstrc, the processor invokes a similarly
invasive replacement method to add the base16 at the end of the config
file.
The procedure is similar to alacritty processor, the danger is also the
same -- it works directly on the config file and will worst case delete
the complete contents of this file. Since the processor is not tested
(other than manually looking that it does what it's supposed to) the
case of this happening is not negligible.
Alacritty does not support including other files into
its configuration yet. As such, this processor needs to
change the user's configuration file *itself*.
This will generally not be a problem, though it can lead
to corrupted configurations in exceptional circumstances
(such as every line being preceded by the process control
regex, for whatever reason).
In general, the processor looks for a specific line in the
following format:
'# Base16 [theme name] - alacritty color config'
from which it will delete everything until it finds a line:
'# Base16End [theme name] - alacritty color config'
So, if you don't want to lose anything -
Do NOT put anything important between those two lines.
This processor is very experimental and will probably still
break every now and again!
Uses ANSI escape sequences to switch all open terminals to desired
theme. Does not yet include capability to permanently set themes, since
this would have to be handled either through xresources or dependent on
the individual terminals color settings (e.g. `.config/alacritty.yml`
for alacritty). Needs further investigation.
Follows my personal rofi setup, which is presumably non-default. Puts
the line including colorscheme into `.config/rofi/themes/settings.rasi`,
I don't remember if that is default. TODO
Also uses base16 templates from the `themes` folder of the package,
which set some *layout* properties of rofi not just color changes.
Should probably look at rofi and create a 'nullifying' rofi rasi file
similar to css plate cleansers and build a default layout from that.
Other way is to use `colors` subfolder of the package, but this does not
connect the colors to uses in the themes, so would be more work to
include.
Xresources processor is very customized and not useable for default
Xresources deployment. It depends on Xresources being available as an
XDG-compliant directory in $XDG_CONFIG_HOME/xresources.
Future work on this processor should start from the default xresources
deployment and allow customization to change it (e.g. through stylerrc
file, setting custom options and paths per processor)
Marty Oehme