If the root pixmap does not fully cover the bar window, some
pseudo-transparent areas were filled with unitialized data, causing
pixelation or other rendering artifacts.
Now, ovserved background slices are first filled with black to make sure
this does not happen and they print an error if not the full pixmap can
be filled.
Fixes#3041
Without override-redirect, i3 will not allow you to have a
non-full-width bar. But polybar simply ignores that request and
continues to render the user-requested width instead of the width i3 has
configured the window to be.
With the 3.7 release, we started setting the window's backing pixmap to
the rendering pixmap. In the case above, the pixmap would only be
allocted for the smaller width and when i3 maps the window, it repeats
the backing pixmap to fill the entire window.
At the point where i3 maps the window, the pixmap contains an initial
render of the bar without module content and that render is then
duplicated.
Reverting back to the old approach of simply copying over the pixmap
after each render does not have that problem and the remainder of the
bar is black (or fully transparent with a compositor).
Ideally, polybar would respect the width i3 configures for it, but that
would break many existing setups that rely on non-full-width bars in i3
Fixes#3060
* Changed bit count for label to use UTF8 standard
Fixes#3074
* label: Calculate length only once
The length calculation has to traverse the whole string
---------
Co-authored-by: nklloyd <nicholask.lloyd@gmail.com>
* Fix backlight initial value matching the actual brightness level
The initial value is `0`. If the actual brightness is also `0` you see
`%percentage%` token as text, it’s not being replaced. Since
`m_brightness` is an `int` the initial value could be just `-1` since
the actual brightness is never goes below zero. Thus this bug will never
show up again because actual brightness on first render won’t match
the “old” `m_brightness` value.
See also for more detailed explanation of the bug:
https://github.com/polybar/polybar/discussions/3079#discussioncomment-8169932
* Add docs
---------
Co-authored-by: Viacheslav Lotsmanov <lotsmanov89@gmail.com>
Modules that don't produce any output are hidden by the controller
(don't have margins or separators).
The tray module should also do that for `format = <tray>` when there are
no icons.
This required the visibility handling to be tied to the module
visibility instead of being handled by the renderer.
Otherwise, the renderer would hide the tray (because the %{Pt} tag was
never sent) and the tray would not unhide when new icons appeared; it
can't differentiate between hidden because empty and hidden because the
module is hidden by the user (the latter is the reason the renderer does
hiding at all).
Fixes#3036
By default, we group workspaces by monitor with the help of
_NET_DESKTOP_VIEWPORT. However, some users may experience this as an
unpredictable "shuffling" of workspaces. While WMs could disable
advertising the property itself, it seems more sensible to handle this
at the level of polybar. Hence, introduce a new group-by-monitor
flag—defaulting to true—which can be used to disable this behaviour.
Closes: https://github.com/polybar/polybar/issues/2603
Related: https://github.com/xmonad/xmonad-contrib/pull/791
Related: https://github.com/qtile/qtile/issues/3375
Co-authored-by: scaramangado <scaramangado@gmail.com>
There is a redirect setup that redirects anything to `/en/stable` (or
whatever the default version is).
This allows us to create version-agnostic direct links that always
redirect to the default version
The `backlight` file seems to not receive modification events for
inotify (it does receive other events though).
These other events still trigger an update, but the value read is still
the old value because the events arrive just slightly before the file is
updated.
The new `poll-interval` setting will inject an event every X seconds to
force an update.
If the actual_brightness file is used, the interval is set to 0 and thus
turned off.
This does not add any more wakeups to the module, the inotify modules
wake up every second anyway and during that time, the interval is
checked.
Fixes#2835
The ewmh strategy has to be dropped because the
`_NET_SUPPORTING_WM_CHECK` window may (at least in bspwm) appear
anywhere in the window stack.
To fix the overlapping monitors issue in #2873, we simply restack
against the topmost of these root windows.
Fixes#2972Fixes#2873 (again)
Search for xcbgen with PYTHON_EXECUTABLE
This way users can specify `-D:PYTHON_EXECUTABLE` to force a certain
python executable and that executable will then also be used to search
for xcbgen.
This should also provide a more universal solution to the configuration
issues with pyenv or conda since the user can just specify
`-D:PYTHON_EXECUTABLE=/usr/bin/python3`.
Using CMAKE_INSTALL_SYSCONFDIR does respect CMAKE_INSTALL_PREFIX, but it
prefixes it to CMAKE_INSTALL_SYSCONFDIR, which results in the default
config being installed to /usr/etc/polybar/config.ini or
/usr/local/etc/polybar/config.ini
CMAKE_INSTALL_FULL_SYSCONFDIR gives an absolute path that respects the
prefix but does the right thing (uses /etc) if it is /usr
Ref: #2770
The module has a poll timeout because it needs to periodically check if
it is shutting down. Otherwise, it would be stuck polling and the bar
couldn't shut down until the script produces a new line.
However, this causes the bar to wake up intermittently (currently
~40/s) due to the 25ms timeout.
Bumping this to 250ms still gives us timely shut downs and caps the
number of wake ups to 4/s.
This is only a stop-gap solution, ideally the script runner is
integrated into the main event loop and uses its polling handles which
don't have to wake up to check for a shutdown.
Ref #1778
Ref #2337
* Added format-x support for ipc_module, tested with demo config
* Certain cases not working
* Certain cases not working, build
* Changed label to output tag, Mixing of default formats wont work
* created changelog
The issue has been fixed in the linux kernel version 5.9 and above so we
are removing our workaround for this from polybar.
Users with older versions can still work around this by explicitly
setting `use-actual-brightness` to false, it is just not done by default
anymore.
Closes#2835
Ref https://bugzilla.kernel.org/show_bug.cgi?id=203905
Ref 69d9f4278d
* better fuzzy matching
Improved fuzzy matching so that it finds the longest matching icon instead of the first possible match
* Update CHANGELOG.md
* removed debug output
* added tests and improved fuzzy finder
- added return statements to the fuzzy finder
- added tests to check whether the fuzzy finder works.
* minor style changes
* minor change to iconset.cpp
* Delete tasks.json
The background_manager used the root window depth for creating its
pixmaps, but when the root pixmap has a different depth, this causes the
copy_area_checked call to fail and crash the bar.
We now load the root pixmap before finding the visual and creating the
slice pixmaps.
Fixes#2798
If any rendered text uses a non-integer number of pixels (often emojis),
rendering of subsequent text blocks will start between pixels which
results in small gaps in the background and over/underline colors caused
by cairo only rendering at fractional-intensity in the beginning and end
pixel.
Simply rounding up text width can solve this.
Fixes#2785
* added kelvin option for module/temperature
* changelog for the changes i made
* fixed typos
* fixed the temperature conversion to be more precise
* Update CHANGELOG.md
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* changed the calculation of the different temperatures
it now uses float as a initial value and makes m_temp temp_k and temp_f by converting and rounding with std::round
* std::lround makes more sense to use than std::round
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
Some distro's build infrastructure (e.g. gentoo) can use
CMAKE_INSTALL_PREFIX to install to a different location.
When the config path is hardcoded to /etc, CMAKE_INSTALL_PREFIX has no
effect.
Ref: https://bugs.gentoo.org/858797
If context_state_callback is called before we call
pa_threaded_mainloop_wait in the main thread, the signal is lost and we
wait forever.
Fixes#2707
Ref #2699
Ref #2697
