summaryrefslogtreecommitdiffhomepage
path: root/src/Xmobar/X11/Draw.hs
AgeCommit message (Collapse)Author
2022-11-08Fixes offset of the pseudo-transparent backgroundKostas Agnantis
2022-09-30Run.Parsers -> Config.Templatejao
2022-09-21better abstracted icon drawing interfacejao
2022-09-20new namespace: Xmobar.Drawjao
2022-09-19wee refactoring (more types in X11.Types)jao
2022-09-19cairo: non-cairo is not an optionjao
2022-09-15cairo: global background always via XRenderjao
2022-09-12cairo: with_xft deprecated, with_cairo synomymjao
2022-09-12wee refactoring: a couple type synonymsjao
2022-09-11cairo: bitmapsjao
2022-09-11fix for the default, non-cairo buildjao
2022-09-11cairo: alpha (still pseudo, via xrender)jao
2022-09-10cairo: fonts, offsets, colors, actionsjao
2022-09-09cairo: pure xlib/xft drawing code factored outjao
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-06Whitespace in the Draw.hs messjao
2022-02-04Xmobar.X11.Parsers -> Xmobar.Run.Parsersjao
2022-02-03Xmobar.X11.Actions -> Xmobar.Run.Actionsjao
2022-01-29Refactoring of the previous patch and its surroundingsjao
2021-11-02hspace feature. Initial intent: make space for a traytulthix
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.)
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-07fix non-exhaustive pattern warningUnoqwy
2020-08-07better parsing for boxes + add marginsUnoqwy
2020-08-07fix line width for boxesUnoqwy
2020-08-07make hlint happyUnoqwy
2020-08-07Fix 1px-off bordersUnoqwy
2020-08-07Add the <box> tag to set borders around textUnoqwy
2020-08-07Refactor ColorInfo to TextRenderInfoUnoqwy
ColorInfo contains background offsets, it is no longer only about colors TextRenderInfo can hold information such as color, offsets, etc
2020-08-07Allow font bg to be taller (or smaller)Unoqwy
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.
2020-08-07Redundant imports (mostly <$>) removedjao
2020-05-10Fix crashes/busy looping happening via indexSibi Prabakaran
Right now, with the `StdinReader` plugin enabled - you can crash/cause busy looping of xmobar if the following html file is opened: ``` <html> <head> <title>hello <fn=1>string</fn> </title> </head> </html> ``` More details about this bug is here: https://github.com/jaor/xmobar/issues/442#issuecomment-625706001 This MR also fixes another bug which produces a crash in xmobar if you pass non integer items between fn: <fn=crash>
2020-02-22Silence some warningsTomas Janousek
src/Xmobar/X11/Draw.hs:51:11-12: warning: [-Wunused-matches] Defined but not used: ‘wr’ | 51 | drawInWin wr@(Rectangle _ _ wid ht) ~[left,center,right] = do | ^^ src/Xmobar/App/EventLoop.hs:50:1-36: warning: [-Wunused-imports] The import of ‘Xmobar.X11.Events’ is redundant | 50 | import Xmobar.X11.Events(nextEvent') | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2018-11-25X11.XUtil -> X11.Textjao
2018-11-25Xmobar.App.Defaults and Xmobar.Config.Typesjao
2018-11-25Xmobar.X11.Actionsjao
2018-11-25Back to app/src, since it seems they're the default convention for stackjao