* Use m_connection.poll_for_event
* fix: Handle X events before polling for IO
Polling the XCB file descriptor for X events doesn't detect events that
are already in XCB's event queue but not yet handled.
If this happens, the eventloop polls for IO and the queued events wait
until another event arrives, causing some desyncs in the bar.
This can easily happen if something (e.g. a click event) triggers some
xcb calls, which as a consequence buffer some incoming events.
We "fix" this by adding a libuv prepare handle (which runs right before
polling for IO) that processes pending X events.
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
The issue was that the event was for the wrapper window and that the
tray_client's move constructors didn't correctly copy over all data and
so when the m_clients vector grew, it corrupted the state of all
existing clients.
Each tray client is directly reparented to the bar window. This saves us
the hassle of having to configure a basically useless tray window and
keeping its background pixmap in sync.
The only disadvantages are having to (un)map each client window
individually and calculating its position relative to the bar window
(which changes all the time) instead of relative to the tray window
(which only changes when clients are added/removed).
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
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
When a module is clicked, only wait for the double click interval if a
double click action is associated with that module. Otherwise trigger
the click right away.
Fixes: #2663
Closes: #1526Closes: #314
* debug log
* semi-working prototype. works on the left and the center but not on the right
* fixes formatting
* fixes tests
* - fixed tray_width_change signal
- implements suggestions
* - fixes error with tray positioning
* - tries to fix tests. Does not work
* - fixes tests
* - implemented suggestions
* reverted formatting in comake and doc
* - changed unique_ptr to const reference
* - fixed formatting errors in code
* - actually fixed formatting(ran clang-format)
* - implemented suggestions
* - Added CHANGELOG.md entry(not sure about wording)
* - removed bar_settings from tray_manager::setup
* - fixed issue from rebase
* - fixed issue with tests from rebase
* implemented suggestions
* Update CHANGELOG.md
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
If two users start a bar with IPC and don't have XDG_RUNTIME_DIR set,
polybar will create the fallback directory `/tmp/polybar`.
However, that directory is only accessible by the user that created it
and so polybar running under the second user will fail to open its
socket there.
We add the UID to the fallback directory to prevent this.
Fixes#2683
* pulseaudio: define reverse-scroll option
When we enable natural scrolling option in libinput,
it sends scroll down event when we swipe up on the touchpad.
This makes the pulseaudio module feel weird.
This option fixes that.
* Update CHANGELOG.md
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
If only cursor-click or cursor-scroll is defined, but not the other, the
bar could try to set the cursor to the empty string which resulted in an
error.
Since polybar sets WM_NORMAL_HINTS, awesomeWM for some reason no longer
respect the position set by polybar before mapping.
reconfiguring the window position once again after mapping the window,
again positions it correctly.
`-Wdeprecated-copy` found this copy-assignment operator, which it
complains about. Since it is just `= default`, we should be able to
remove both it and the default constructor, making the struct just its
data members.
If any action block contains a negative offset, it can cause text to be
theoretically be rendered outside of the block, making that text not
clickable.
To fix this, we ensure that an action block starts at the lowest
observed position while the block is open and ends at the highest
observed position while it is open.
Fixes#1814
When polybar is remapped (either through IPC or something like xdo
show), openbox positions it somewhere on the screen using the same
positioning algorithm as it would for regular windows.
If the position and size is set in the WM_SIZE_HINTS atom, openbox will
respect the position and size declared by the window.
Fixes#2021
* add units support (POINT, PIXEL, SPACE) for polybar
- add a size_with_unit struct
- add a geometry_format_values struct
- move dpi initialisation from renderer.cpp to bar.cpp
- add a string to size_with_unit converter
- add point support (with pt)
- add pixel support (with px)
* Fix unit test compilation
* clang-format
* Better names
The old names didn't really capture the purpose of the structs and
function.
space_type -> spacing_type
space_size -> spacing_val
size_type -> extent_type
geometry -> extent_val
geometry_format_values -> percentage_with_offset
* Remove parse_size_with_unit
No longer needed. The convert<spacing_val> function in config.cpp
already does all the work for us and always setting the type to pixel
was wrong.
In addition, line-size should not be of type spacing_val but extent_val.
* Cleanup
I tried to address most of my comments on the old PR
* Fix renderer width calculation
We can't just blindly add the x difference to the width because for
example the width should increase if x < width and the increase keeps
x < width.
Similarly, we can't just add the offset to the width.
* Rename geom_format_to_pixels to percentage_with_offset_to_pixel
* Cleanup
* Apply suggested changes from Patrick on GitHub
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Update src/components/bar.cpp
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Update src/components/config.cpp
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Update src/components/builder.cpp
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* Update src/components/builder.cpp
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* config: Use stod for parsing percentage
* Use stof instead of strtof
* units: Fix test edge cases
* Remove unnecessary clang-format toggle
* Use percentage_with_offset for margin-{top,bottom}
* Support negative extent values
* Rename unit to units and create a cpp file
* Move percentage_with_offset_to_pixel unit test to units
* Add unit tests for units_utils
* Clarify when and how negative spacing/extent is allowed
Negative spacing is never allowed and produces a config error.
Extents allow negative values in theory, but only a few use-cases accept
it.
Only the extent value used for the `%{O}` tag and the offset value in
percentage_with_offset can be negative. Everything else is capped below
at 0.
The final pixel value of percentage_with_offset also caps below at 0.
* Fix parsing errors not being caught in config
* Print a proper error message for uncaught exceptions
* Cleanup module::get_output
All changes preserve the existing semantics
* Stop using remove_trailing_space in module::get_output
Instead, we first check if the current tag is built, and only if it is,
the spacing is prepended.
* Remove unused imports
* Restore old behavior
If there are two tags and the second one isn't built (module::build
returns false), the space in between them is removed.
For example in the mpd module:
format-online = <toggle> <label-song> foo
If mpd is not running, the mpd module will return false when trying to
build the `<label-song>` tag. If we don't remove the space between
`<toggle>` and `<label-song>`, we end up with two spaces between
`<toggle>` and `foo`.
This change is to match the old behavior where at least one trailing
space character was removed from the builder.
* Add changelog entry
* Remove unused setting
* Use percentage with offset for tray-offset
Co-authored-by: Jérôme BOULMIER <jerome.boulmier@outlook.fr>
Co-authored-by: Joe Groocock <github@frebib.net>
* eventloop: Use eventloop namespace in cpp files
* changelog: Add missing deprecated hook message
* Make eventloop and ipc classes non-copyable and non-movable
* Remove functional.hpp
* eventloop: Don't close handles in error cases
Client should be responsible for closing handles.
* eventloop: Address invalidation of handle references
Deprecates not using `polybar-msg` for IPC.
Fixes#2532Closes#2465Fixes#2504
* Create FIFO specific NamedPipeHandle subclass to PipeHandle
* Prototype SocketHandle
* Move mainloop up to main.cpp
* Pass eventloop to ipc class
* Deprecate sending ipc over the named pipe
Unfortunately, we can only show the warning in the polybar log and not
give the user any feedback because the pipe is one-way
* Move eventloop into its own namespace
* Prototype ipc socket handling
* Remove handles from ipc_client
Should be independent from eventloop logic
* Remove ipc clients when finished
* Add tests for ipc_client decoding
* Add callback for complete ipc messages
* Remove template param from mixins
* Move signal handler to new callback system
* Move poll handle to new callback system
* Move FSEventHandle to new callback system
* Move TimerHandle and AsyncHandle to new callback system
* Move PipeHandle to new callback system
* Implement socket functionality in new callback system
* Correctly reset ipc named pipe handle
* Let client close handles in error callback
* Wrap client pipe and ipc::client in connection class
* Better decoder log messages
* Socket path logic
* Fix CI warnings
* Remove UVHandleGeneric
* Fix error when socket folder already exists
* Proof of concept message writeback
* Restructure ipc files
* polybar-msg: Use sockets
* polybar-msg: Better syntax for actions
* Fix memory leak with fifo
After EOF, the pipe wasn't closed and EOF was called all the time, each
time allocating a new pipe.
* Make polybar-msg compile on its own
* Rudimentary writeback for polybar-msg
* Fix payload reference going out of scope.
* Add IPC documentation
* Cleanup polybar-msg code
* Specify the v0 ipc message format
* Close ipc connection after message
* Fix ipc tests
* Properly close ipc connections
* Fix polybar-msg not working with action string
* Write polybar-msg manpage
* polybar-msg: Stop using exit()
* ipc: Print log message with PID
* Add tests for ipc util
* polybar-msg: Print PID with success message
* ipc: Propagate message errors
* Rename ipc::client to ipc::decoder
* Rename ipc.cpp to polybar-msg.cpp
* ipc: Write encoder function and fix decoder bugs
* ipc: Use message format for responses
* ipc: Handle wrong message types
* ipc: Write back error message if ipc message cannot be processed
This only happens for commands and empty actions.
Non-empty actions are not immediately executed, but deferred until the
next loop iteration.
* Remove TODO about deleting runtime directory
The socket file is not deleted after socket.close() is called, only
after libuv executes the close callback.
So we can't just call rmdir because it will probably always fail.
* CLeanup WriteRequest
* Update manpage authors
* Cleanup
This fixes#857 and #1932. Also replaces PR #1725, since we don't need
our own implementation of condition_variable anymore since people who
update their polybar should have GCC 10 by now.
The m_updated_at field of the mpd module was removed instead of having
its clock change because it became unused in commit 645a3142a1.
This adds a new `tray-foreground` config option, and uses it instead of
the `tray-background` setting to build up the `_NET_SYSTEM_TRAY_COLORS`
property. I'm pretty sure that the previous behavior was a mistake (this
was introduced in 94298741b6 which is a
pretty large diff). For me and some other people, this results in a
black icon being drawn on top of a black background, which is pretty
useless! I would say that this diff fixes
https://github.com/polybar/polybar/issues/2235. Note: the old code dealt
with `unsigned int` and maxed values out at 0xff. The new code deals
with `uint16_t` and maxes values out at 0xffff. I haven't found the
relevant documentation to justify this change, but from manually
testing, I'm pretty confident this is the right change.
This all matches pretty closely with this code from i3:
[`i3bar/src/xcb.c::init_tray_colors`
code](43e805a00d/i3bar/src/xcb.c (L1490-L1522)),
which you can see also uses the bar's foreground color and maxes values
out at 0xffff, not 0xff.
If you merge this up, I think we should also update
https://github.com/polybar/polybar/wiki/Configuration#bar-settings to
mention the new settings.
Fixes#2235
We had a check that restricted config files to "regular files".
This check was to restrictive as it didn't allow for things like:
```
polybar -c <(gen_config)
gen_config | polybar -c /dev/stdin
```
Now, polybar can easily read config data from stdin.
* Handle relative includes
We change to the directory of the given config file before parsing.
This allows us to handle relative includes.
TODO: Maybe improve the name of the change_dir() function.
* Fix unused result warning
* Add `relative_to` parameter to expand()
If the path is relative, we resolve it by prepending
dirname(config) to the path.
Add dirname() - Returns the parent directory of the file or an empty
string.
* Resolve relative paths
Handle paths relative to the current file being parsed.
* Remove unneeded change_dir()
* Fix expand()
`is_absolute` is calculated after we expand the path.
`relative_to` must be a directory.
Add test for expand() with relative paths
* Recalculate `is_absolute` after expanding `path`
* Add more file_util::expand tests
* Add changelog
Co-authored-by: patrick96 <p.ziegler96@gmail.com>
Before it was enabled by default. That means if the constructor fails,
the destructor will complain that the module was not stopped before
deconstructing.
We can't just call stop if module creation fails because the module is
only partially initialized.
* The xworkspaces module should wait for EWMH to become available
Before this change if EWMH wasn't available the xworkspaces module was
permanently disabled. When polybar was started alongside the window
manager e.g. from .xinitrc this caused a race condition between polybar
and the window manager and the xworkspaces module may or may not be
displayed. After this change polybar will wait for EWMH to become
available. This change closes#1915, see that issue for more details.
Curiously this only required the removal of the error condition which
used the be raised when EWMH wasn't available. The xworkspaces module
will show up on the bar as soon as the first EWMH event is processed by
the existing event handling code. I can't argue much about the
correctness of this patch but it seems to work flawlessly in my testing
with xmonad. I didn't test any other window managers. Note that removing
the error condition below which checks that _NET_DESKTOP_VIEWPORT is
available might make this work with pin-workspaces=true. I couldn't test
the effects of that change because I only tested with xmonad and xmonad
doesn't support _NET_DESKTOP_VIEWPORT, so I didn't make that change.
* xworkspaces: Remove check fo _NET_DESKTOP_VIEWPORT
Implementations that don't support it will just return an empty list for
get_desktop_viewports and pin-workspaces won't do anything.
* Update changelog
Fixes#1915
Co-authored-by: Tim Schumacher <tim@timakro.de>
Co-authored-by: patrick96 <p.ziegler96@gmail.com>
* WIP ipc actions
* feat(ipc): Add hook, prev, next and reset actions
Closes: #2464
* ipc: format code
* ipc: fix comparison
* Apply suggestions from code review
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
* ipc: make index 0-based
* ipc: add 0-based indexing breaking change to Changelog
* ipc: restore 1-based index for and message
* ipc: fix initial=0 throwing an error
Co-authored-by: Martin Terneborg <martinterneborg@protonmail.com>
Co-authored-by: Patrick Ziegler <p.ziegler96@gmail.com>
