* 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).
Since APP_VERSION is different for every commit and almost all file
include settings.hpp, the whole project has to be rebuilt for every
commit. With this, hopefully, this can be greatly reduced and only
changed files need to be rebuilt. This will also help ccache
Some people use text modules instead of the `separator` key in the bar
section to better configure the separator (colors, fonts).
Since we disallowed the same module being used multiple times in #1534,
this will now print an error message.
This should help with this a bit.
Ref #1913
Since all of polybar is built at once, there is no chance that this is
ever linked to an object that was compiled with another `-std=`
Ref: https://stackoverflow.com/a/46857525/5363071
Some WMs like i3 discard position information when unmapping the bar and
because of that the bar would be at the wrong position after being
remapped.
Fixes#1484
Ref: https://github.com/i3/i3/pull/3834
* refactor: Use flat module list if possible
Before if you wanted to iterate over all loaded modules you had to first
iterate over all blocks and then over their modules even if you didn't
care about alignment.
* refactor: setup modules in separate function
* controller: Print error for duplicate modules
You can't use the same name twice inside the module lists
E.g.
modules-left = a b c
modules-center = a
modules-right = b
would print an error.
We only print an error for now because we don't want to break existing
configs. But in the future this should be properly enforced.
A workspace is occupied if it is not active and there is at least one window managed by the WM (`_NET_CLIENT_LIST`) that has set `_NET_WM_DESKTOP` to that workspace.
The behavior when `_NET_WM_DESKTOP` is not set is not yet clear but this is unlikely to happen since most WMs will position windows on some desktop.
Closes#874Fixes#1444Fixes#1033
* Set Desktop OCCUPIED if a window moves there
This covers more of an edge-case. I did this first by accident, it might
vanish later on.
* Replace tracking change of WS with currently used WS
* Untrack occupied workspaces
* Track windows and their desktops in pairs
* Match type of occupied_desktops with current_desktop
Because the index needs to be matched later on, type mismatches would be non-ideal.
* Recreate the occupied desktops everytime and remove duplicates
* Readd support for moving windows to other desktops
* Use less characters to empty the vector
* Rename variable storing the desktops
* Recount windows on every occasion
This alone simplifies the management and the lookup for occupation of a
workspace
* Keep track of number of windows in every workspace
* Add debugging output that shall be removed before merging
* Remove obsolete TODO
* m_client_list should always be diff'd, since the desktop may change
Therefore we update the desktop-count tally every time the client_list
changes. It may just be a desktop-change without a change of
clients.size()...
* Add more logging-spam to understand window/desktop lifecycle
* Lock event-handler to serialize handling of events
* Fix occupied workspace counting and change to bool array
Also, performance improvements when diffing new and old client lists
* Fix crash when all clients are removed
* Conform to linter and styleguide
* Shorten conditional as it is standard enough
Since this only guards against 0-divisions, it can be shortened
without risking too much confusion down the road.
* Guard against multiple threads accessing and modifying data
Fixes#1444
Modification of internal data happens through the handle-method, while
the build-method tries to access the data structures for display. Since
some modifications clear e.g. the m_viewports, references may become
invalid between looping over them an accessing them.
The mutex should guard against this simultanuous access.
* Do not 'adopt_lock', because calls come from very different threads
To my understanding, adopt_lock has some dependency on the mutex-ownership. Since
the lock is once called from the inside (in handle) and once from the outside (in
build), there might be a problem. After brief testing, the segfaults happened fewer
times.
See #1444
* Also listen to _NET_WM_DESKTOP
In order to move a window from one desktop to another, it is sufficient
to set the desktop-property of that window. xmonad fires a lot of events
in the case of moving a window, herbstluftwm only updates the
_NET_WM_DESKTOP-atom of the window.
This change reloads the clientlist in order to correctly set the
desktop state "occupied".
* Describe need and use of mutex
It might be possible to relieve the guard in xworkspaces_module::handle,
but I am unsure about this. Since xmonad emits a lot of events on almost
every minor change, I would let the guard keep its post, avoiding
race-conditions in event-handling.
* Give temporary variables better names
* Clarify purpose of loop
About 80% of this comment are taken from
https://github.com/jaagr/polybar/pull/882#discussion_r255317363
* Remove merge-remainder
* Use a simpler method to list occupied desktops.
Co-authored-by: Jérôme Boulmier <jerome.boulmier@outlook.fr>
* Document m_clients field
While an update was forced whenever polybar was made visible, the
`m_lastinput` variable was still set to the same value as when the bar
became hidden because updates to it were prevented.
Fixes#1875
This fixes a regression introduced in
56e24992df where relative config file
paths weren't recognized because file_util::expand just added a slash
to the beginning.
That is calling `polybar -c config example` would try to load the config
file at `/config` instead of using the relative path as before.
In all other cases where expand is used this change shouldn't matter
because polybar only accepts absolute paths everyhwere else.
Theoretically this would now allow relative paths (relative to the cwd
where polybar was called) but this shouldn't used (or documented)
because that behavior will change when merging #1523 which would make
paths relative to the polybar config.
Ref #1523
Ref 56e24992df
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)
When adding a string to the builder directly, it would parse the string
for formatting tags, delete them and readd them with the methods in the
builder that keep track of open tags so that we can properly close them
when flushing.
This parser has a bug, it parses multiple formatting tags in a single
block as a single tag, e.g.
%{F#000000 u#FFFFFF +u}
would be parsed as an `F` tag with value `#000000 u#FFFFFF +u` which is
of course wrong.
Removing the parsing step fixes this problem in the simplest way
possible. This has two benefits:
* Building of modules is sped up because we don't have to do the parsing
step in the builder and many modules use this function to add strings
from a progressbar (which already has properly closed tags).
* We don't have parser logic in two places. Until now both `parser.cpp`
and `builder.cpp` actually parsed formatting tags. This leads to a lot
of code duplication and, as we've seen, bugs.
All of the modules that use this function to add text already make sure
that they properly close formatting tags (mostly by using the builder to
generate the strings)
NOTE: This change slightly changes polybar's behavior. Raw tags (tags
added by the user through the config) can now have their effects reach
neighboring modules because the builder doesn't track and thus doesn't
close them on each flush. This can (and will) be resolved by resetting
all tags at module borders.
Fixes#1555
There really is no reason to also close over/underline tags when we have
a right margin and a non-black over/underline color.
The git blame for these lines also doesn't give us any insights as to
why it was done this way.
