On laptops and similar devices, RandR sometimes returns zero active
screens, for example when closing a laptop's lid before it suspends.
Don't restart in that case because the new polybar instance will see
zero screens and quit. Instead, just ignore those kind of events.
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
checkout is bumped from v3 to v4, there shouldn't be any breaking
changes (just bumps the node version)
upload-artifact is bumped from v2 to v4, our use case shouldn't break
github-script is bumped from v3 to v7. I don't see any breaking changes
that should affect us. Again mainly a nodejs version bump
checkout is bumped from v3 to v4, there shouldn't be any breaking
changes (just bumps the node version)
upload-artifact is bumped from v2 to v4, our use case shouldn't break
github-script is bumped from v3 to v7. I don't see any breaking changes
that should affect us. Again mainly a nodejs version bump
Unaware users may be confused by why the tray module is not shown in the
default config and if they add it, they may be confused why only one of
their bars shows the module.
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
