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 adds `monitor-exact = true` in the bar section
This also properly does best-match instead of first-match if multiple
matches exists. For example if there are two monitors HDMI2 and HDMI-2
and we try to match HDMI-2 with monitor-exact = false, until now HDMI2
would be matched. Now exact matches are always preferred.
Fixes#1532
This adds a new label in the bspwm module `label-marked`
This flag for focused nodes of a focused desktop was introduced in [1]
and released with bspwm 0.9.4
It adds the `M` flag to `G` type items in bspwm's report format
Resolves#1552
[1]: d0138af475
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>
* Clean up CMake logic
- removed logic to find CppUnit (no longer used)
- removed "dirs" variable used to pass include directories
- removed add_library function (no longer used)
- removed make_executable function
* only used in 2 places (polybar and polybar-msg)
* it was more general than needed, logic is simpler without it
- split polybar into static library and executable
* this allows linking unit tests to the library
* rename library
* add coverage build
- Added a CMake build type "Coverage" that builds C and C++
code with the "--coverage" flag (recognized by both GCC and Clang)
- removed "-Wno-missing-field-initializers" from test flags,
since it didn't seem to be needed any more
- removed logic from tests/CMakeLists to disable "-Werror" and "-pedantic-errors"
since there didn't seem to be any warnings during the build
* fix whitespace
* update travis
* remove O2 from defalt flags
* allow tests to be built by default make target
* disable Werror for debug builds
wireless_tools 29 redefines inline in iwlib.h as:
#define inline inline __attribute__((always_inline))
which conflicts with POLYBAR_NS, which is defined as:
#define POLYBAR_NS \
namespace polybar { \
inline namespace APP_VERSION_NAMESPACE {
In version 30.pre9 this #define is moved into a source file and thus
cannot conflict.
The error only occurs when building with clang, so it seems gcc and
clang handle this differently
Fixes#1492
If a tailed command is used polybar would generate two action tags, one
with %counter% replaced and one with %pid% replaced, but never both
This is a bug that was introduced in #934
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.
We need to use positions relative to the position of the bar for indexing into
the background image slice, but the code used absolute ones.
This worked fine as long as absolute positions are the same as relative
positions (this is the case for a bar located at (0,0), so if bottom = false).
But for bottom bars (where the bar position is not (0,0)) this was wrong which
caused the tray background to be black (out of bounds for the background slice).
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.
This option is no longer necessary because the tray background color can now
simply be set to any (semi-)transparent color (just like the bar background).
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.
Now all the tokens in the memory module also have ramp and bar counterparts.
These can be used exactly the same as `bar-used` and `ramp-used`, they are named `<bar-swap-used>`, `<bar-swap-free>`, `<ramp-swap-used>`, and `<ramp-swap-free>`
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
The repeatone button doesn't influence repeating behaviour at all, so
the name is misleading.
This deprecates icon-repeatone for now, until we can completely remove
it
Fixes#1279
This patch enables support for nl80211. In case the libnl-genl-3.0
library isn't found, it will fall back to Wext instead.
The library to use can also be manually set with the CMake option
WITH_LIBNL.
The Wireless-Extensions (WE or Wext) are deprecated and long replaced
by cfg80211.
Although Wext isn't used by WiFi drivers anymore, CFG80211_WEXT allows
old tools to communicate with modern drivers by providing a wrapper
API.
The only reason polybar couldn't build without xkb is because the
xkeyboard module's source file was not removed during compilation.
xkeyboard already has an entry in unsupported.hpp
This effectively makes xcb-util-xkb optional
When xrm was disabled, main.cpp was missing the complete defintion of
connection from connection.hpp, which was included xresources.hpp when
xrm was enabled.
It's queried the same way ipv4 addresses are queried, but here it displays globally routable addresses. If there are multiple such addresses, it picks one (same as with ipv4). It's possible that an address discovered this way is not in fact globally reachable but still marked as global.
Using brace initialization here causes bar.hpp to not compile when
included on its own, forcing all clients to also include
tray_manager.hpp and so on, which defeats the purpose of forward
declaring those classes.
This also allows us to remove the tray_manager.hpp, renderer.hpp and
parser.hpp includes from the clients of bar.hpp
As mentioned in #1215, gcc >=8 will complain, if strncpy truncates the
source string or gcc can prove there is no NUL terminating byte.
This also updates the i3ipcpp submodule where there was a similar error
Fixes#1215
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
There have now been several instances of people reporting that their
bars are not found and polybar not printing the config file name because
the error is thrown first, making it very difficult to debug
Before, polybar would crash, trying to throw a server error because
mpd_connection_get_server_error asserts that the error is of type server
error, but it isn't because it was cleared
When using the same token multiple times in the same label with
different length properties, polybar would always use the settings for
the first token. This now replaces the tokens one by one, so that a new
token object is used for the length settings each time a token is used
again. Because the token objects are added in order, the replacement
always uses the right token object for the token that is replaced.
Fixes#971
Only updating when an mpd event occurred would cause issues when mpd was
playing and the machine was put to sleep because the elapsed time was
calculated by taking the time difference of the last update and now
which would give you wrong numbers, if the machine was in standby in
between.
Since the update function on the module is only called once a second (or
when an event happens), we can just update the data every time without a
huge performance hit.
Fixes#915
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.
For nested actions, the inner action should override the outer action.
But because the list of actions was not iterated in reverse the outer
action was matched first.
Fixes#760
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
expand-right defaults to true to preserve the current functionality
If set to false, the items in the menu will be added to the left of the
toggle label (instead of the right side)
Should resolve the issue discussed in #655
Curl removed that header in 73a2fcea0b4adea6ba342cd7ed1149782c214ae3
([1])
http.cpp doesn't use anything from that header and compilation works for
fine with curl 7.54.1
Fixes#647
Ref:
[1]: 73a2fcea0b
When focusing a desktop with the urgent flag, two events are received
from `bspc` simultaneously, separated by a newline character.
This was not handled correctly and the second event was discarded causing
the urgent style to be removed, but the focused style would remain on the
previously focused desktop.
This fixes the problem by handling any number of events that arrive at the
same time (separated by newlines).
This helps ensure that when a string is truncated it is not done in the
middle of a utf8 multi-byte sequence. This doesn't 100% correspond to
user-perceived characters, but it should be pretty close in most cases.
Since 3.4, `/proc/meminfo` contains a `MemAvailable` field, which polybar uses to determine
`(gb|mb)_free` and `(gb|mb)_used`. This commit adds a fallback for when `MemAvailable` does
not exist, allowing a fairly-accurate approximation on older kernels.
This commit also removes the reliance on the exact order fields appear in `/proc/meminfo`.
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}
