In polybar-msg, the connection handle was captured as a reference to a
shared_ptr, but the shared_ptr went out of scope right after.
This probably always caused UB, but was only noticeable for two or more
instances.
* Return shared_ptr from eventloop
* Add -Wdeprecated-copy-dtor warning
Produces a warning if classes don't have explicit copy operations if
they have a user-defined constructor.
This helps us stick to the rule of 5 (kinda, no warnings for missing
move operators).
* Clean up eventloop
* Fix compiler warnings
* Fix fs_event_handle_t name
* 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
* 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
* 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
