Only modules can now be action handlers.
This also slightly simplifies the controller because we don't need to
keep track of input handlers, we can just use the module list.
All modules now expose their actions as public static constants
Issues: The menu module no longer closes when an item is clicked (before
it would intercept any executed command and look if it matches one of
its exec commands)
the `node` and `node_repeat` were never called with the optional
parameter add_space. And its default value is false, so the
corresponding code was never used.
I think in general it is better to just have the user of those functions
call `builder::space` when they need to instead of adding more
complexity to the `node*` functions.
* Add label minlen and alignment.
Fix build
* Update src/drawtypes/label.cpp
Co-Authored-By: infokiller <infokiller@users.noreply.github.com>
* Use existing alignment type.
* Remove redundant max_len handling in label::get.
* Fix shadowing.
* Add label alignment tests.
* Handle minlen/maxlen and alignment in same function.
Also add a test for a test case brought up in the PR discussion.
* Format files with clang-format
* Move builder::get_label_text tests into label tests
builder::get_label_text doesn't really do anything anymore
* builder: remove get_label_text
* label: Clean up label::get()
* Fix comment style.
* Set default label alignment to left.
* Update src/drawtypes/label.cpp
Co-Authored-By: Patrick Ziegler <p.ziegler96@gmail.com>
* Update include/drawtypes/label.hpp
Co-Authored-By: Patrick Ziegler <p.ziegler96@gmail.com>
The %{PR} tag is introduced for this. It resets all colors as well as
the activation of the underline and overline and font.
This has become necessary because we don't track what raw tags a user
injects into the formatting string and otherwise their raw tags could
bleed through.
This doesn't touch action tags because even before raw action tags
weren't being tracked. Action tags also have the requirement that they
have to be used in pairs, so closing them prematurely could break things
(for example with click actions for the entire bar)
When adding a string to the builder directly, it would parse the string
for formatting tags, delete them and readd them with the methods in the
builder that keep track of open tags so that we can properly close them
when flushing.
This parser has a bug, it parses multiple formatting tags in a single
block as a single tag, e.g.
%{F#000000 u#FFFFFF +u}
would be parsed as an `F` tag with value `#000000 u#FFFFFF +u` which is
of course wrong.
Removing the parsing step fixes this problem in the simplest way
possible. This has two benefits:
* Building of modules is sped up because we don't have to do the parsing
step in the builder and many modules use this function to add strings
from a progressbar (which already has properly closed tags).
* We don't have parser logic in two places. Until now both `parser.cpp`
and `builder.cpp` actually parsed formatting tags. This leads to a lot
of code duplication and, as we've seen, bugs.
All of the modules that use this function to add text already make sure
that they properly close formatting tags (mostly by using the builder to
generate the strings)
NOTE: This change slightly changes polybar's behavior. Raw tags (tags
added by the user through the config) can now have their effects reach
neighboring modules because the builder doesn't track and thus doesn't
close them on each flush. This can (and will) be resolved by resetting
all tags at module borders.
Fixes#1555
There really is no reason to also close over/underline tags when we have
a right margin and a non-black over/underline color.
The git blame for these lines also doesn't give us any insights as to
why it was done this way.
Using a bit vector to track the active attributes does not really give a
significant speed increase, especially for only two attributes
Checking if a syntaxtag or an attribute exists in the map just adds
unnecessary code
Was around since the first commit but no documentation why. It was only
used in the text module and doesn't appear in any public documentation,
so this doesn't break anything.
Trimming the quotes in labels and the date module are not needed at all,
because surrounding quotes are removed when loading the values from the
config.
Removing the quotes in the builder also doesn't seem to serve any
purpose at all.
The check of the maxlen and ellipsis condition was also moved to the
label creation, this way get_label_text doesn't need to care about the
restrictions placed on maxlen and ellipsis
atoi, atof and so on have undefined behavior if anything goes wrong. We
now use strto*, but without error checking. In most places overflows and
the like *should* not happen. String to number conversions are only used
when reading data from other applications or from the config, if another
application gives unparsable strings or too large numbers, then most
likely there is something wrong with that application. If the error
comes from the user config, then the user has to live with values
provided by strto* on error (which are very reasonable)
Fixes#1201
This removes the spacing tinkering when parsing format specs.
The following example uses the old behavoir:
format-test = <label-foo> <label-bar>
format-breaks = <label-foo><label-bar>/<bar-test>
`format-test` would replace all occurences of ' ' with the
a space string with defined `spacing` as its width. `format-breaks` would
not validate as the tags where split with ' ' as delimiter.
All that nonsense has been removed and each tag is extracted as is.
The `spacing` parameter can still be used to apply N extra whitespaces
between the tags, but it is now 0 by default.
Build the format sub-strings (%fill%, %indicator%, %empty%)
before adding it to the builder to avoid having it generate
alot of duplicate content (tags, etc)
Make it possible to set different size
and color values for the two properties.
`overline-size = 2`
`overline-color = #f00`
`underline-size = 5`
`underline-size = #00f`
