The renderer now only stores the positions of the actions because that
is specific to the renderer and because the actual position can only be
finalized after all the rendering is done because intitially the
positions are relative to the alignment and not the bar.
The variables storing the current colors, attribute activations and font
were only used in a single place and can easily also be read from the
context.
This allows us to remove a lot of the state of the renderer.
* refactor(color): Use enum class for color type
* Add testcases for tag parser
* Make tag parser a pull-style parser
Being able to parse single elements at a time gives us more fine-grained
error messages, we can also parse as much as possible and only stop
after an exception.
* fix(color): Parser did not check for invalid chars
* tag parser: First full implementation
* tag parser: Fix remaining failing tests
* tag parser: Replace old parser
* tag parser: Treat alignment as formatting tag
Makes the structure less complex and the alignment tags really are
formatting tags, they are structurally no different from the %{R} tag.
* tag parser: Cleanup type definitions
All type definitions for tags now live in tags/types.hpp, the parser.hpp
only contains the definitions necessary for actually calling the parser,
this shouldn't be included in many places (only places that actually do
parsing). But many places need the definitions for the tags themselves.
* Rename components/parser to tags/dispatch
* tag parser: Cleanup
* Add changelog
It is useful for people to see what config file polybar loaded.
For debugging font issues people almost always need to check what fonts
polybar loaded, for that they need to run polybar with info logging. Now
this information is always provided. This requires an update in the font
wiki page.
The old code didn't really work when the right block was pushing against
the center block. Also `fixed-center` wasn't properly defined. I have
now fixed it to the following:
* `fixed-center = true`: The center block stays at the center of the bar
whenever possible. It can be pushed to the left if the right block takes
too much space and to the right if the left block takes too much space
* `fixed-center = false`: The center block will be in the middle between
the left and right block whenever possible. If there is not enough space
between those two, the center block will be directly to the right of the
left block and pushes out the right block
The issue was that it used the position of the center module to
calculate the leftmost possible position of the block. However, if the
center module is empty that position is disastrously wrong.
Fixes#591Fixes#1903
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)
Polybar had issues when there is no background set or set by a tool like imagemagick which doesn't add the root pixmap to the root window properties.
There's not much we can do about it, but at least polybar doesn't crash anymore.
Fixes#1582Fixes#1585
* fix(tray_manager): only enable transparency if neccessary
Previously, we always enabled transparency
* fix(background_manager): avoid needless fetching
* fix(renderer): move logging message to correct place
* fix(background_manager): handle dummy pixmap (_XSETROOT_ID) right
* fix(background_manager): more initialization + don't free on error
Freeing on error is incorrect, since we could still be called again later in
which case we still need the resources.
* fix(background_manager): add more infos to trace logs
* fix(background): correct typo (XROOTMAP -> XROOTPMAP)
* fix(background_manager): do not report "no background" as error
* style(background_manager): use braces for if
Co-Authored-By: bennofs <benno.fuenfstueck@gmail.com>
* fix(background_manager): better error message for dummy pixmap
Co-Authored-By: bennofs <benno.fuenfstueck@gmail.com>
* style(background): some more style fixes
* fix(connection): initialize pixmap in all cases in root_pixmap()
* style(connection): improve readability using early return
This patch adds support for observing multiple slices of the desktop background.
This is used for the tray so that it doesn't have to rely on the bar's rect to
get the desktop background. In particular, it now handles the case where the
tray is not contained fully within the bar's outer rect (for example, when using tray-offset-{x,y})
Co-Authored-By: bennofs <benno.fuenfstueck@gmail.com>
The idea is that pseudo-transparency should behave like real transparency as
much as possible. To achieve this, we now render the bar the same way in both
cases. The only part where pseudo-transparency differs is at the very end, where
the rendered bar is captured and composited against the desktop background
image. This should ensure that both modes behave the same.
This reverts some behaviour differences introduced by the pseudo-transparency
implementation. The new implementation is much closer to the
non-pseudo-transparent case and thus keeps original behaviour.
For the new method we simply fill the bar with the background image fetched from
the root window if in pseudo-transparent mode, otherwise we do nothing. This
means that everything will work as in the fully-transparent mode.
The systray only supports pseudo transparency (real transparency would require
much larger changes) so the real transparency should only be used for the bar itself.
We now take the bar position that the window manager gives us instead of trying
to calculate it ourselves. This is more correct when multiple bars are attached
to the same edge, as the window manager may move some of them in that
case (assuming override redirect is not enabled)
We need to fetch the outer area from the root window, not just the inner area
because we paint the background below the borders as well.
This has the nice effect of supporting semi-transparency for borders as well.
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
Fixes#759 by only drawing text background when its color is different from the background color of the bar itself.
Explicitly setting a module's background to `background-0` now stops working.
The changes introduced in 389bae2669 to
address #551 did not consider the left border
Now center modules are centered regardless of border (left or right)
settings or tray position
Fixes#672
This tries to mimic the old renderer's behavior as closely as possible.
In the absence of any information, DPI is assumed to be 96x96. DPI can
be configured on a per-bar basis using the configuration key "dpi".
To use the DPI configuration from Xresources (if built with support),
one can specify the following in the bar config:
dpi = ${xrdb:Xft.dpi:96}
