| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What used to be called `eventLoop` didn't process any X11 events at all,
rename to `signalLoop` to signal that it really deals just with xmobar
signals.
|
|
In f8c835a33a7a, I flipped the discard flag to XSync to False on a false
assumption that it may discard events from under the eventer thread
(since renamed to handleXEvent). This can't happen—the eventer thread
and the main loop do not share a Display connection, they have two
separate ones. Turns out, the main loop doesn't read/process any events
from its Display connection, which is why it was necessary to discard
them once in a while.
The fix restores that discarding, adds a comment to explain why that
discarding should stay, and just to make things a bit cleaner, also
prevents some of those events from being emitted in the first place: by
configuring the graphics context that we don't want any exposure events
(https://tronche.com/gui/x/xlib/events/exposure/graphics-expose-and-no-expose.html).
Fixes: f8c835a33a7a ("Fix delayed reaction to USR1/2 signals")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While using xmobar to reproduce/fix a bug in xmonad I noticed that
xmobar doesn't react immediately to the signals to reposition or change
screen.
Apparently none of the Xlib functions called from `repositionWin` flush
the Xlib output buffer (XMoveResizeWindow is known to not flush,
although it's unfortunately not documented), so when compiled with the
threaded runtime that runs XNextEvent in a separate thread, the
reposition is sent to the X server only later when other stuff happens.
With all monitors set to refresh once a minute, this can take a looong
time.
(It's entirely possible this happens even without the threaded runtime,
I didn't test that, sorry.)
The fix is to call XSync at the end of `repositionWin`.
While at it, I spotted that drawInWin calls XSync with discard=true,
which seems like a mistake. We don't want to discard any events, do we?
(In practice, I'd expect the `eventer` thread to read all events even
before the drawing thread manages to discard them, so even if this
discarding XSync ever had any reason to be there, I don't think it does
anything meaningful these days. I may be wrong, though.)
|
|
This reverts commits c6669e26e1 (partially; changelog entry kept),
73e02934d6, 78efa5900a.
These commits were introduced as a workaround for a double UTF-8
encoding bug in xmonad-contrib which itself was meant to be a
fix/workaround for another issue. We have now identified the underlying
issue and fixed it right at the root, so this entire cascade of hacky
(and wrong) workarounds can be safely reverted. Thankfully, none of the
xmonad-contrib hacks made it into a release, so there's no backward
compat to worry about.
Should anyone be interested in the details,
https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
provides a summary and links to all the related issues and PRs.
Related: https://github.com/jaor/xmobar/pull/482
Related: https://github.com/jaor/xmobar/issues/476
Related: https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
Related: https://github.com/xmonad/xmonad-contrib/pull/471
Related: https://github.com/xmonad/xmonad-contrib/issues/377
|
