summaryrefslogtreecommitdiffhomepage
path: root/src/Xmobar/X11
AgeCommit message (Collapse)Author
2022-09-15cairo: global background always via XRenderjao
2022-09-14whitespacejao
2022-09-14cairo: honouring top/bottom offsets in color specificationsjao
2022-09-13cairo: ellipsize text segments if they go out of boundsjao
2022-09-13cairo: honouring iconOffsetjao
2022-09-13XlibDraw: verticalOffsets in XConf not neededjao
2022-09-13'Core' fonts not used anymore (utf8 is always required)jao
2022-09-12X11.MinXft not needed anymorejao
2022-09-12cairo: with_xft deprecated, with_cairo synomymjao
2022-09-12wee refactoring: a couple type synonymsjao
2022-09-11cairo: a couple of as yet unused imported foreign functionsjao
2022-09-11x event loop clean-upsjao
2022-09-11cairo: bitmapsjao
2022-09-11fix for the default, non-cairo buildjao
2022-09-11cairo: lintingjao
2022-09-11cairo: alpha (still pseudo, via xrender)jao
2022-09-11cairo: outer borderjao
2022-09-10cairo: left/center/right segmentsjao
2022-09-10cairo: <hspace>jao
2022-09-10cairo: fonts, offsets, colors, actionsjao
2022-09-09cairo: drawing skeleton from an xlib cairo surfacejao
2022-09-09cairo: pure xlib/xft drawing code factored outjao
2022-08-13fix: default to textOffset for missing textOffsets entriesjao
2022-04-18New dbus signal: SetAlpha (fixes #499)jao
2022-02-17Refactoring: Clean up naming of X11 event loop threadsTomas Janousek
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.
2022-02-17Fix memory leak in drawInWinTomas Janousek
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")
2022-02-13Use nh' for displaying the bar on the bottom of the screen. Fixes #555exorcist365
2022-02-06Whitespace in the Draw.hs messjao
2022-02-06Little refactoring: forkThreadjao
2022-02-04Refactoring: event loop handling simplificationsjao
2022-02-04Xmobar.App.X11EventLoop -> Xmobar.X11.Loopjao
2022-02-04Xmobar.X11.Parsers -> Xmobar.Run.Parsersjao
2022-02-04Xmobar.App.CommandThreads -> Xmobar.Run.Loopjao
2022-02-03Xmobar.X11.Actions -> Xmobar.Run.Actionsjao
2022-01-29Refactoring of the previous patch and its surroundingsjao
2022-01-29Basic Xmobar.App.TextEventLoopjao
2022-01-29Whitespacejao
2021-11-02hspace feature. Initial intent: make space for a traytulthix
2021-07-12Nit, for homogeneity's sakejao
2021-07-12Add TopH and BottomH for only controlling height of the window. (#556)Joan MIlev
2021-05-14Fix delayed reaction to USR1/2 signalsTomas Janousek
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.)
2021-04-27Revert "Conditional encoding …" and "Avoid double utf8 encoding" (#482)Tomas Janousek
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
2021-04-26Workaround for hlint failureTomas Janousek
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.
2021-04-26Fix off-by-one in strut calculation for Static positionTomas Janousek
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
2020-11-15Fix crash on <fn=1>x</fn> when no additional fonts are specifiedTomas Janousek
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
2020-11-15Fix vertical centering of additional fontsTomas Janousek
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)")
2020-08-09A bit of documentation for <box>jao
2020-08-09Update changelog and add commentSibi Prabakaran
2020-08-09Conditional encoding of xft stringSibi Prabakaran
2020-08-09Avoid double utf8 encodingSibi Prabakaran
With this change, xmobar should respect the data which it gets. Xmobar should just render the data instead of trying to encode it.