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.
Using a bit vector to track the active attributes does not really give a
significant speed increase, especially for only two attributes
Checking if a syntaxtag or an attribute exists in the map just adds
unnecessary code
Was around since the first commit but no documentation why. It was only
used in the text module and doesn't appear in any public documentation,
so this doesn't break anything.
This is the next step to merge #1237 in stages.
Currently there are barely any restrictions on how the config can be
written. This causes things like config files with DOS line endings to
not be parsed properly (#1366) because polybar splits by `\n` and when
parsing section headers, it can't deal with the `\r` at the end of the
line and thus doesn't recognize any section headers.
With this PR we introduce some rules as to what characters are allowed
in section names and keys.
Note: When talking about spaces I refer to any character for which
`isspace()` returns `true`.
The rules are as follows:
* A section name or a key name cannot contain any spaces as well as any
of there characters:`"'=;#[](){}:.$\%`
* Spaces at the beginning and end of lines are always ignored when
parsing
* Comment lines start with `;` or `#` and last for the whole line. The
whole line will be ignored by the parser. You cannot start a comment at
the end of a line.
* Section headers have the following form `[HEADER_NAME]`
* Key-value lines look like this:
`KEY_NAME{SPACES}={SPACES}VALUE_STRING` where `{SPACES}` represents any
number of spaces. `VALUE_STRING` can contain any characters. If it is
*surrounded* with double quotes (`"`), those quotes will be removed,
this can be used to add spaces to the beginning or end of the value
* Empty lines are lines with only spaces in them
* If the line has any other form, it is a syntax error
This will introduce the following breaking changes because of how
underdefined the config syntax was before:
* `key = ""` will get treated as an empty string instead of the literal
* string `""`
* Any section or key name with forbidden characters will now be syntax
errors.
* Certain strings will be forbidden as section names: `self`, `root`,
* `BAR`. Because they have a special meaning inside references and so a
* section `[root]` can never be referenced.
This replaces the current parser implementation with a new more robust
one that will later be expanded to also check for dependency cycles and
allow for values that contain references mixed with other strings.
This PR also now expands the config paths given over the command line so
that `--config=~/.config/polybar/config` resolves properly.
Closes#1032Closes#1694
* config_parser: Add skeleton with tests
First step in the config_parser develoment. Only tests functions that
are easily testable without many outside dependencies. Integration tests
will follow.
* config_parser: Implement parse_header
* config_parser: Implement get_line_type
* feat(string): Add trim functions with predicate
Not only trimming based on single character matching but based on a
freely specifiable predicate. Will be used to trim all spaces (based on
isspace)
* config_parser: Implement parse_key
* config_parser: Implement parse_line for valid lines
* config_parser: Throw exception on invalid lines
* config_parser: Remove line_no and file_index from parse_line
Cleaner to let the caller catch and fill in the line number and file
path
* string: Clear up misleading description of trim
Before, trim would remove all characters that *didn't* match the
predicate and thus the predicate isspace wouldn't work correctly. But
because we used the inverse (isnospace_pred) it all worked out, but if
the function was used with any other function, it wouldn't have given
the desired output
* config_parser: Implement parse_file
* config_parser: Switch operation to config_parser
This changes the way the config is invoked. Now main.cpp creates a
config_parser object which then returns the singleton config object from
the parse method. Subsequent calls to config::make will return the
already created config object as before
The config_parser does not yet have all the functionality of the old
parser: `inherit` directives are not yet resolved. Other than that all
the old functionality is implemented (creating sectionmap and applying
include-file)
Any sort of dependency detection (except for include-file) are still
missing
* config: Move xrm initialization to constructor
config_parser handles the detection of xrdb references and passes that
info to the config object.
This finally allows us to delete the config::parse_file function because
everything in it has been implemented (except for xrdb detection and
file error handling)
* refactor(config_parser): Cleanup
* config_parser: Set config data after initialization
Looks much cleaner this way
* config_parser: Expand include-file paths
* config_parser: Init xrm if the config uses %{xrdb references
* config_parser: Use same type of maps as in old impl
Polybar has some weird, not yet fixed, inheriting behaviour and it
changes depending on the order in which the config stores its data.
Using the same type of maps ensures that the behaviour stays the same.
* refactor(config_parser): Clearer invalid name error message
* config_parser: Don't allow reserved section names
Sections with the names 'self', 'BAR', 'root' could never be referenced
because those strings have a special meaning inside references
* config_parser: Handle inherit directives
This uses the old copy_inherited function, so this still suffers from
crashes if there are cyclic dependencies.
This also fixes the behaviour where any key that starts with 'inherit'
would be treated as an inherit directive
* config_parser: Clearer dependency cycle error message
* refactor(config_parser): Handle file errors when parsing
This removes the need to check if the file exists separately
* fix(config): expand config file path
Now paths using ~ and environment variables can be used as the config
path
* fix(config): Properly recognize xrdb references
* config_parser: Make messages more informative
* doc(config): Improve commenting
Comments now describe what the config_parser actually does instead of
what it will do.
We also now follow the rule that single line comments inside functions
should use `//` comments
* refactor: Move else on same line as curly braces
* fix(config_parser): Don't duplicate paths in `files`
* refactor(config_parser): Use else if for clarity
* fix(config): Undefined behavior in syntax_error
Before the custom what() method produced undefined behavior because the
returned string became invalid once the function returned.
* refactor(config): descriptive name for useless lines
is_valid could easily be confused as meaning syntactically invalid
without it being clarified in a comment
* refactor(config): Use separate strings instead of key_value
Takes just as much space and is much better to read
* fix(config_parser): TestCase -> TestSuite and fix macro call
Ref: #1644
* config_parser: use const string& in method args
* config_parser: Improve comments
* config_parser: Incorporate review comments
The binary is not needed to compile and run polybar with pulseaudio
support. Though of course there is no use in having a pulse module when
you don't have pulseaudio installed.
In the AUR optdepends means that the package can run without optdepends
installed. In polybar most features, if enabled at compile time, cannot
run without their dependencies and will crash polybar. Now the
optdepends only contains truly optional dependencies.
Polybar can run without the i3-wm package because it only relies on the
`i3` executable and is not dynamically linked against any library in i3.
Breaking Changes:
* In the `internal/memory` module all of the megabyte values no longer have decimal places (#1606).
Changelog
**New Config Options**
The following config options were added:
In the `[bar/*]` section:
* `monitor-exact`, use exact name matching for monitors otherwise ignore dashes.
In formats:
* `format-NAME-font` to set the font for that format (same as `label-NAME-font`)
In `internal/bspwm`:
* `label-marked` for the new `marked` node flag introduced in baskerville/bspwm@d0138af
In `internal/xkeyboard`:
* `label-indicator-(on|off)` is used once for every indicator (caps lock, etc.), supports `%name%` and `%icon%`
* `label-indicator-(on|off)-(capslock|numlock|scrolllock)` overwrites `label-indicator-(on|off)` for the given indicator
* `layout-icon-*` is a list that maps layout names to icons to be used with the `%icon%` token in `label-layout`
* `indicator-icon-*` is a list that maps indicator names to icons to be used with the `%icon%` token in `label-indicator-*`
In `internal/temperature`:
* `base-temperature` is the counterpart to `warn-temperature` and controls the lower bound for the ramp.
**Deprecations**
* xkeyboard: `label-indicator` is deprecated in favor of the new `label-indicator-on`
**Features**
* bar:
* make exact monitor matching configurable (#1533), see #1532
* `border-size` now supports the same mixed percentage/pixel sizes as `width` and `height` (#1592), see #1567
* Use primary monitor if no monitor is specified (#1426), #1412
* bspwm: Support for the new `marked` node flag. (#1557), see #1552
* format: Formats now support the `-font` property just as labels (#1602), see #19
* network: Support for all tokens in all labels (#1597)
* xkeyboard: Indicator names can be customized. Also adds icon mappings for layouts and indicators (#1559, #1048), see #1558
* temperature: The ramp now starts at `base-temperature` instead of 0°C (#1706), see #1703
* battery: `%percentage_raw%` token that displays the real percentage regardless of `full-at` (#1756), see #1753
**Fixes**
* network: Display `N/A` when no IPv4 address can be found (#1597)
* xworkspaces: Properly handle when desktops are removed from `_NET_DESKTOP_NAMES` (#1713), see #1710
* backlight: Read the right brightness value (#1689), see #1180
* pulseaudio: Allow volume increase when it is close to the maximum. Before it did not allow that when adding `interval` would go over the max. (#1765)
* i3: fix workspace change for workspaces with special characters in the name (#1798), see #1797
* font: Characters no longer vanish when the `size` or `pixelsize` property is 0 (#1646)
* build:
* Compilation error under gcc9 (#1729), see #1728
* Compilation no longer fails when new flags are introduced that produce new warnings (#1735)
* Use GNUInstallDirs instead of hardcoded paths
This change should be a no-op in the normal case and at the same time make it
easier to customise polybar builds on systems with special needs.
* Avoid creating /usr/share/doc/polybar/polybar/*
* Include GNUInstallDirs for the doc target itself
* cmake: Don't try to set CMAKE_INSTALL_* variables
Since we include GNUInstallDirs all these variables are already set
* cmake: Print install directories in summary
* fix(cmake): Make doc-only work like normal build
This is kind of a dirty hack to force CMAKE_INSTALL_DOCDIR to use
`polybar` as the project name when only polybar-doc is built.
Maybe it is wiser at some point to be able to do a doc only build (and
install) that can be done from the top level project. Then we would also
not need to include GNUInstallDirs here
Originally the size function returned the scaled `size` property for
scalable fonts and the non-scaled `pixelsize` property for non-scalable
fonts. This caused lots of issues when that property was 0 (empty bars,
characters not drawn without warning, see references at the bottom).
This behavior was mostly observed on debian where `size` is set to 0 if
`pixelsize` is set.
We now try to use both properties for both types, but prefering `size`
for scalable fonts and `pixelsize` for non-scalable ones.
This behavior doesn't break existing correct behavior but now never
returns 0. It will always try to fall back to the other property or to
some fallback value if both properties are 0.
I originally thought this could also make font patterns more expressive
by being able to specify the size of scalable fonts directly in pixels
like so:
Unifont:size=0:pixelsize=20
or to scale non-scalable fonts by forcing polybar to fall back to the
`size` property (which is always scaled):
Wuncon Siji:pixelsize=0:size=20
But how these two patterns are matched by `fc-match` depends both on the
font and on the distro/fontconfig setup.
Ref #706
Ref #1450
Ref #1257
I don't know the original intention behind this but it clutters up debug
traces and basically makes ccache useless.
The only benefit it has, giving version info in stacktraces, is kind of
void since we already ask for version information on github issues.
Previously, when volume was in close proximity to n_max_volume, a larger
increase would not do anything. After this patch, volume is set to
m_max_volume in such scenarios. If the volume already is at
n_max_volume, we mirror the old behavior and emit a warning.
So, for example, consider m_max_volume was 100%, but the volume prior
to the increase was 96%. An increase of 5% would do nothing (emit a
warning, even) instead of setting the volume to 100%.
Note that this might happen even if the volume is at 95% according to
%percentage% due to rounding errors.
Displays real percentage instead of being set to 100 if percentage > full-at
* battery: added percentage_raw token, which ignores full-at
* battery: current_percentage returns raw, added clamping function instead
* battery: clamp percentage used by build()
Made clamp_percentage() const to allow its usage inside build()
* battery: read and return percentage in one line
Whenever a new gcc version is released that introduces new warnings,
this breaks lots of builds on the user's side. This change pushes the
detection of these new warnings a bit back until either a user reports
warnings or developers get the new compiler updates. I think this is a
good tradeoff since release builds are no longer totally broken as soon
as a new compiler version comes out.
Travis still uses -Werror because there we actually want builds to fail.
