The client window has to be added to the save set after it has been
reparented. Otherwise if the reparenting fails weird stuff happens
(windows in the save set have to be child windows of windows created by
the current connection).
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.
Because the X server is asynchronous, there is no guarantee that after
reading _NET_CLIENT_LIST, all windows still exist.
For that reason we need to handle XCB_WINDOW errors appropriately.
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.
