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.
* 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 Gitter room https://gitter.im/polybar/polybar should serve a similar
purpose as the IRC room with the benefit that messages persist and can
be received when offline.
From now on gitter should be the place where the polybar community
lives. Reddit is great for asking longer questions in the style of a
forum but not so great for quick back and forth conversations. IRC is
better in that aspect but has the serious downside that you have to stay
connected to get an answer and messages are not logged (only by your
client).
Both reddit and IRC are here to stay and I will still check them
regularly, but we should encourage people to join gitter.
None of the payload fields seem to be used. They were the only place
where EVENT_SIZE was used and why it had to be a macro (no variable
length arrays).
