|
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.)
|
|
Pixel intervals in _NET_WM_STRUT_PARTIAL are closed, not open [1], so
xmobar of width 1920 at x=0 needs to be encoded as ⟨0, 1919⟩, not ⟨0,
1920). The code already does this for Top/Bottom positioning, but Static
has been buggy for years.
[1]: https://specifications.freedesktop.org/wm-spec/1.5/ar01s05.html#idm46075117229424
Fixes: https://old.reddit.com/r/xmonad/comments/mynegr/xmobar_dual_monitor_bug/
Fixes: https://github.com/jaor/xmobar/issues/530
|
