Because of how monitors are removed inside the loop and depending on the
monitor order a cloned monitor may be assigned a width of 0 but is never
actually removed resulting in polybar saying the bar is out of bounds
Fixes#1794
Removing monitors is not really necessary when selecting the monitor
where to render the bar or choosing the backlight. Since both monitors
occupy the same coordinates rendering can be done on both and it's
better to give people felxibility for the backlight.
Fixes#1191
Premature optimization that tried to cache monitors but the cache did
not take into account the parameter values.
The call `get_monitors(..., ..., false, true);` would get all connected
and unconncected monitors a subsequent call
`get_monitors(..., ..., true, false);` would get back the same list of
monitors even though it requested only connected monitors.
Additionally `get_monitors` is never called periodically so the
optimization really didn't help much.
The github module only authenticate by query string, and this method is deprecated:
https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters
There is no reason to remove it before the method stop working, so I've made possible to the user choose which authentication method he will use:
* The parameter token remain unchanged.
* If the parameter user is passed then the module will use the not deprecated method, passing user and token on the body of the requisition. Otherwise the module will use the deprecated method.
Co-authored-by: Lucas <araujo.lucasvale@gmail.com>
Fixes#2002
If an exact match was possible, fuzzy matching could still return a
non-exact match if it appeared before the exact match in the list of
icons.
Fixes#2041
With this we no longer distribute the jsoncpp 1.7.7 source with polybar.
It is possible that polybar will no longer build on older systems that
have an ancient version of jsoncpp (>= 5 years).
Ref: polybar/i3ipcpp#9
Adds `format-offline` and `label-offline`
* feat(github): offline label & fixes
* Clear label if there are no notifications and empty-notifications = false
* clang-format
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
In the case where _NET_NUMBER_OF_DESKTOPS > |_NET_DESKTOP_NAMES|
the last branch of the get_desktop_names method would return a vector
with _NET_NUMBER_OF_DESKTOPS + 1 elements because we iterate until
_NET_NUMBER_OF_DESKTOPS + 1.
Fixes#1983
In master gtest fails to build with the error
/home/travis/build/polybar/polybar/build/googletest-src/googlemock/include/gmock/gmock-more-actions.h:138:1: error: ISO C++11 requires at least one argument for the "..." in a variadic macro [-Werror]
ACTION_P(ReturnPointee, pointer) { return *pointer; }
We had a lot of failed builds because gtest often breaks stuff in
master. From now on we will just use a release tag. Whenever there is a
new release, we manually update this file.
Ref: google/googletest#2678
Functionality-wise reverts the changes from #1534
In #1907 we have decided to allow the same module to appear multiple
times (and deliver actions to all matching modules). But since that PR
will likely take longer to get merged, I want to remove the error from
polybar because the message it prints isn't really true anymore.
* Added -j and --jobs as command line options
* Added parallelizing option to the set_build_opts function
* Aligned parallel option to the previous options
This is dependent on a PR to xpp that does the same. Newer compilers
(GCC10 in particular) are stricter about which headers provide the
std exception types.
Before, if the command produced no output, the `m_output` field would
not have been overwritten and the old output was displayed.
But since this is an explicit trigger of the hook, the user would expect
the output to be updated to whatever the script produces (even if that
is nothing).
Ref: https://www.reddit.com/r/Polybar/comments/e9a8ww
xorgproto always was a make dependency (I think) but it was
automatically included indirectly by another dependency.
Arch recently cleaned up some xorg related packages which made xorgproto
no longer an indirect dependency of polybar which spams cmake with
messages like:
```
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
Package 'xproto', required by 'xau', not found
Package 'xproto', required by 'xdmcp', not found
```
And during `make` finally completely fails the build because some
library's include directories are not honored because the xproto.pc file
cannot be found:
```
In file included from /home/patrick96/Projects/github.com/patrick96/polybar/include/cairo/utils.hpp:3,
from /home/patrick96/Projects/github.com/patrick96/polybar/src/cairo/utils.cpp:3:
/usr/include/cairo/cairo-ft.h:46:10: fatal error: ft2build.h: No such file or directory
46 | #include <ft2build.h>
| ^~~~~~~~~~~~
```
Ref: https://bugs.archlinux.org/task/64892
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 `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.
