summaryrefslogtreecommitdiffhomepage
path: root/src/Xmobar/App
AgeCommit message (Collapse)Author
2022-01-29Refactoring of the previous patch and its surroundingsjao
2022-01-29Basic text output, without colors, workingjao
2022-01-29Basic Xmobar.App.TextEventLoopjao
2022-01-29Xmobar.App.CommandThreadsjao
2022-01-29Whitespacejao
2021-11-07Fail when reading a SignalChan, parse signal from defaultConfig.John Soo
* Address code review comments on ipc-improvements.
2021-11-07Let xmobar be used with a signal TMVar when used from other haskell.John Soo
2021-11-02hspace feature. Initial intent: make space for a traytulthix
2021-07-06Filter filename when executing Haskell-based configslotThe
We are now—in case the user specified a Haskell file as their xmobar configuration—threading the command line arguments that xmobar receives to the relevant execv() call. However, we simply shove in all arguments originally given to xmobar, including the path to the configuration file. As main is now defined within that very file, this seems unneccessary. By filtering out that part of the arguments, the pattern that a lot of users seem to follow for easy setting of certain options becomes a little bit nicer. For example: main :: IO () main = getArgs >>= \case ["-x", n, _] -> xmobar . config $ read n _ -> xmobar $ config 0 becomes main :: IO () main = getArgs >>= \case ["-x", n] -> xmobar . config $ read n _ -> xmobar $ config 0 Related: https://github.com/jaor/xmobar/pull/553
2021-07-01Pass arguments if using xmobar.hsalternateved
2021-03-18Fix typo `DRTSOPTS` -> `RTSOPTS`Claudio Bley
The cpp option `-DRTSOPTS` results in `RTSOPTS` being defined.
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-10-09additionalFonts command-line option: --add-fontivanbrennan
Provide an option the user can specify any number of times to add to the additionalFonts config field.
2020-10-09hlintingjao
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-08-07Don't get confused by empty configuration dirs (fixes #313)jao
By checking full paths, instead of just dirs (option 1).
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-04-12Add trailing linefeed to --version output.Zev Weiss
2020-02-26Copyright yearsjao
2020-02-23Timer coalescing: handle exceptions in timer coordination threadTomas Janousek
This corrects my (wrong) assumption that the timer coordination thread will only fail if there's an error in the code, and in that case any attempt to recover is futile. It turns out that the thread does fail recoverably in one notable case: when running in the non-threaded RTS, registerDelay fails immediately. And we probably still wish for xmobar to support the non-threaded RTS. One way to solve this issue is to add a bunch of #ifdefs and compile the code only in the threaded case. This would double the number of configurations that need to be tested, though. Instead, let's make the code robust against all kinds of exceptions in the timer coordination thread, and get non-threaded RTS support for free.
2020-02-22Timer coalescing: gracefully uncoalesce slow timersTomas Janousek
The first implementation assumed all timers (monitors) are fast and frequent (which happens to be the case in my configuration). This meant that a single on-line weather monitor could block the entire xmobar instance for a long time due to the refresh pausing (meant to reduce power consumption). This commit attempts to fix that by limiting the refresh pause time and using the old periodic sleep method for these slow timers (monitors).
2020-02-22Implement timer coalescing (noticeably less CPU/power usage)Tomas Janousek
xmobar currently runs every monitor in its own thread. Monitors that do periodic updates simply sleep and loop. This unfortunately leads to these threads coming out of sync, and xmobar ends up waking up and redrawing for every periodic monitor. In my case, that is 7 times per second, which is enough for xmobar to be at the top of "top" with more than 1% CPU usage, and to have a noticeable impact on battery life. This commit adds a central timer coordination thread which makes sure that periodic updates happen together and that we only redraw once they're all done. Together with PR #409, I managed to lower the idle power draw of my laptop from 4W to 3W.
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') | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-10-15A second attempt at fixing #405jao
This time taking into account that ~/.config/xmobar could be populated
2019-10-14Don't create .xmobar if it doesn't exist (issue #405)jao
2019-09-06Write error log to data dir, not conf dirChuck
Write xmobar.errors to XMOBAR_DATA_DIR, not XMOBAR_CONFIG_DIR. This allows XMOBAR_CONFIG_DIR to be read-only. This brings xmobar into alignment with how xmonad manages its analogous directories (before this change, a read-only DATA dir worked with xmonad but not with xmobar).
2019-03-17Copyright noticejao
2019-01-12Honour flags when no config file is available (fixes #375)jao
2018-12-09New exposed function: configFromArgsjao
2018-12-08Compiling only .[l]hs[c] filesjao
Should take care of issue #371
2018-12-04Fix: honour command line flagsjao
Fixes #370, and then some
2018-12-02Fix: exposing the Command constructors in libjao
2018-12-01Propagating RTS compilation flags to recompilejao
2018-11-30Self-compilation a la xmonadjao
2018-11-30XMobar.App.Optsjao
2018-11-26Lintingjao
2018-11-26Compilation functions lifted from xmonadjao
2018-11-26Utilities for dealing with config and data directoriesjao
2018-11-26App.Defaults -> App.Configjao
2018-11-25Xmobar.System.Utils, Xmobar.X11.Eventsjao
2018-11-25X11.XUtil -> X11.Textjao
2018-11-25Xmobar.App.Defaults and Xmobar.Config.Typesjao
2018-11-25Xmobar.App.Mainjao
2018-11-25Xmobar.X11.Actionsjao
2018-11-25Xmobar.App and small refactoringsjao