The change in #2270 accidentally broke how we access module types.
module<Impl>::TYPE always points to the module superclass and it thus
accesses its empty TYPE field.
This mainly broke legacy action handling.
Ref #2270
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.
This allows us to identify module by their type and it is also better to
store the module type as part of the module instead of having it
hardcoded in factory.hpp
Action strings now have the form '#MODULE#ACTION'
For example to trigger the action 'toggle' in the 'module/date' module
one would now use '%{A1:#date#toggle:}'
With this action strings can now be uniquely assigned to one module.
Fixes#1172
Any timer_module based module would sleep for the set interval and then
continue running. Depending on the start time of polybar this
sleep pattern might not be aligned, which causes such modules to always
update in a shifted manner.
Consider the date module as an example. If the update interval is set to
60 seconds and polybar was started at 13:37:37, polybar would update the
clock at 13:38:37, 13:39:37 and so on.
To make matters worse, if a module would perform lengthy checks this
interval might drift over time, causing even more inconsistent updating.
This patch extends the base module with a sleep_until method that calls
the corresponding function on the sleephandler. Additionally the
timer_module is extended to compute the remaining time until the next
interval passes and sleep accordingly.
Closes#2064
Co-developed-by: Dominik Töllner <dominik.toellner@stud.uni-hannover.de>
Co-authored-by: Malte Bargholz <malte@screenri.de>
A warning implies something went wrong and (possibly) the user should do
something about it. However, warnings are not always used this way.
For example:
* When a fallback value for a `${..}` reference is used, this shouldn't
produce a warning (or notice) since using fallbacks is not something
bad.
* pulse telling you that it uses the default sink because no sink was
specified also does not warrant a warning (even notice may be too
high).
* Whenever polybar shuts down it produces a "Termination signal
received..." warning. Since there isn't a more proper way to shut down
polybar, it should not produce a warning. Same argument for a
`screenchange-reload`
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)
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.
