| 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
|
|
hlint started failing recently:
src/Xmobar/X11/Text.hs:121:32: Error: Parse error: on input `-'
Found:
textExtents (Utf8 fs) s = do
let (_,rl) = wcTextExtents fs s
> ascent = fromIntegral $ - (rect_y rl)
descent = fromIntegral $ rect_height rl + fromIntegral (rect_y rl)
return (ascent, descent)
It's probably a change in the parser or something, didn't really look
into it, just changed it to something that's parsable.
|
|
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
|
|
This fixes the following crash that happens with the default xmobar
configuration (using HOME=/ makes xmobar ignore ~/.xmobarrc):
$ echo "<fn=1>x</fn>" | HOME=/ xmobar
xmobar: Prelude.!!: index too large
Commit 3e9e1cb9d300 ("Fix crashes/busy looping happening via index")
meant to fix this but apparently it only fixed indexing of fontlist, not
voffs, so the crash was still there.
Fixes: https://github.com/jaor/xmobar/issues/504
|
|
The readme says additional fonts are centered vertically if a
corresponding offset isn't specified in `textOffsets`, but this didn't
happen as we used the first font's metrics for centering of all fonts
instead.
Fixes: a2365debfaba ("New configuration parameter `textOffsets` (fixes #311)")
|
|
|
|
|
|
|
|
With this change, xmobar should respect the data which it gets. Xmobar
should just render the data instead of trying to encode it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ColorInfo contains background offsets, it is no longer only about colors
TextRenderInfo can hold information such as color, offsets, etc
|
|
Implemented only for XFT fonts.
Adds a new "part" in the fc tag.
> Example: <fc=white,gray:0>foo bar</fc> will make the font background
as tall as the bar (absolute offset, here set to 0 for both top &
bottom)
Changes ColorString to ColorInfo, containing both top and bottom
offsets. The "colors string" is still in only one string.
|
|
|
|
|
