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
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>
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
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)
When using `get_screen_resources`, XRandR will query the hardware to
detect any change. This takes some time.
`get_screen_resources_current` uses the cached information and is
pretty fast.
In my case, the information is always already present in cache because
it was set by the program that did configure the screens (autorandr in
my case, but this applies to most frontends). As polybar is not used
to configure stuff, I think this is fine. There should be something
configuring the screen before polybar is able to use it.
However, maybe some people are using `polybar --list-monitors` just
after plugging a screen. It won't display the new screen in this case.
So, maybe this is not a good idea. It makes polybar starts
faster (500ms faster in my case when there are 3 screens plugged).
Also, I did this change because running `polybar --list-monitor` in
parallel with starting `polybar` (in a for loop for example), I get
some curious bug where my screens disappear and reappear. I don't need
this change as this was easy to fix by avoiding the parallel access to
XRandR properties, but maybe this would avoid other people running
into the same problem.
Your take!
Positions the bar window above the _NET_SUPPORTING_WM_CHECK window
The generic restacking strategy now first tries the ewmh strategy, the
the bottom strategy.
Prints the output and exit code of 'i3 --get-socketpath' if it fails and
prints the socket path if the connection fails.
Ref polybar/i3ipcpp#13
Ref #2942
* Remove unused function
* Refactor deprecation warning
* Modules take config as parameter instead of using the singleton
* Bar take config as parameter instead of using the singleton
* Renderer take config as parameter instead of using the singleton
* Legacy Tray Manager take config as parameter instead of using the singleton
* Screen take config as parameter instead of using the singleton
* Controller take config as parameter instead of using the singleton
* Remove the config singleton
* Apply review suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Apply style suggestion
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
---------
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
The tray should be vertically centered in the inner area of the bar.
Unequal top and bottom borders should not affect the alignment relative
to other text.
Fixes#2950
tray-padding determines space added before and after each icon
tray-spacing determines space added between icons (but not at the edge)
Both are an extent value and accept both pixel and point values.
The size accepts a percentage with offset relative to the bar height and
determines the width and height of tray icons.
Defaults to 66%
Does not affect spacing
Currently, we don't support 32-bit visuals and don't set
_NET_SYSTEM_TRAY_VISUAL
It is unclear what happens if the default visual (which is used as a
fallback if _NET_SYSTEM_TRAY_VISUAL is not set) is 32-bit.
In that case, we may need to explicitly use a 24-bit visual.
