summaryrefslogtreecommitdiffhomepage
path: root/src/Xmobar/App
AgeCommit message (Collapse)Author
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