summaryrefslogtreecommitdiffhomepage
path: root/src
AgeCommit message (Collapse)Author
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-08-07String index as progress barjao
2020-06-23Fix hlint warningsSibi Prabakaran
2020-06-23Update based on feedback on the PRSibi Prabakaran
2020-06-23Hlint fixesSibi Prabakaran
2020-06-23Some formatting of codeSibi Prabakaran
2020-06-23More cleanupSibi Prabakaran
2020-06-23Cleanup and add some testsSibi Prabakaran
2020-06-23Fix warningsSibi Prabakaran
2020-06-23Further optimizationSibi Prabakaran
2020-06-23More efficient formattingSibi Prabakaran
2020-06-23Optimize CPU monitorSibi Prabakaran
2020-06-23Add some optimizationSibi Prabakaran
2020-06-13Look up only the first coretemp.N/hwmon dir in MultiCoreTempjao
2020-06-13Version bump, changelog, readmejao
2020-06-13Detection of Tdie and Tctl for Ryzen temperaturesjao
2020-06-13Initial support for benchmarks of the pluginsSibi Prabakaran
2020-06-12Update UVWeather branchSibi Prabakaran
2020-06-12Optimize weather plugin by reusing manager and other refactorsSibi Prabakaran
As documented in the http-client library, calling newManager is an expensive operation: ``` Creating a new Manager is a relatively expensive operation, you are advised to share a single Manager between requests instead. ``` But inspite of the haddocks in xmobar claiming that once 'Manager' is created, it will be used throughout the monitor is not true. Because for every call of `startWeather` a new manager is being created. Also I removed the option in WeatherOpts because even if it is false, it will be ultimately created in `getData` function. Also without using a manager - the plugin won't really work. So, I don't think there is any reason for this option to exist. I have introduced a new dependency http-client-tls to use the shared global manager so that we reuse the same manager every time. This simplifies a lot of code. Note that this is not really a new dependency because http-conduit already depends on it transitively.
2020-06-05Optimize date pluginSibi Prabakaran
We avoid calling getTimeZone for each of the time the date has to be updated. Instead, it's computed once at the start and re-used for each invocation. Looking at the implementation of 'getTimeZone', we can see that it's very expensive: https://www.stackage.org/haddock/lts-15.15/time-1.9.3/src/Data-Time-LocalTime-Internal-TimeZone.html#getTimeZone It calls a C FFI each time to get the time zone (getTimeZoneCTime). This is something which we can avoid and the MR implements that. I have been using my xmobar with this patch and the result has been quite good. My xmobar CPU usage has used to hit 3~7% intermittently. With this MR, It hits only 0.7% intermittently which is nice. :-)
2020-05-19hlintingjao
2020-05-19Add EOF check before getLine operation from stdinSibi Prabakaran
Fixes https://github.com/jaor/xmobar/issues/442
2020-05-17Temporarily restore Stdin to its previous statejao
2020-05-11more hlintingjao
2020-05-11hlintingjao
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-05-06recursively hlintingjao
2020-05-06hlintingjao
2020-05-02Update stderr and the bar on receiving exceptionSibi Prabakaran
2020-05-02Avoid busy looping by not catching all exceptionsSibi Prabakaran
This specifically avoids situation described in this issue https://github.com/jaor/xmobar/issues/438 where the handle was throwing the IOException continously in a loop: <stdin>: hGetLine: invalid argument (invalid byte sequence) It happened because my system's environment was right, but the proper behaviour hear would be to let it to throw the exception rather than leading to a busy loop. I did some git blame to find out that this commit introduced the behaviour: https://github.com/jaor/xmobar/commit/fc24dc1874dcf7c9e66e21502a58b40cbe627c85 but there was no reason mentioned in the commit for trying to capture all exceptions.
2020-04-30Spurious import and hlintingjao
2020-04-30Refactor the usage of hGetLineSafeSibi Prabakaran
hGetLineSafe is always hGetLine and hence we can directly use it.
2020-04-21Whitespacejao
2020-04-21MPD: catch errors earlier so that reconnections are allowedjao
2020-04-12Add a HandleReader PluginPavan Rikhi
This adds a new `HandleReader` plugin, which displays data from a Haskell `Handle`. This is really only useful if you are running xmobar from within another Haskell program, but lets you avoid the mechanics of creating a named pipe with the proper file permissions. Instead, you can use `System.Process.createPipe` to make a pair of read & write Handles. If you pass the read handle to HandleReader, you can use hPutStr on the write Handle to send data to xmobar from your application code.
2020-04-12Add trailing linefeed to --version output.Zev Weiss
2020-03-05Network: up indicatorjao
2020-03-05Wireless: fix hlint warnings, reenable CI checksPaul Fertser
This makes the code hlint-clean for --cpp-define=USE_NL80211, --cpp-define=IWLIB and without --cpp-define too.
2020-02-26Copyright yearsjao
2020-02-26hlint nitjao
2020-02-25Wireless: support NL80211 userspace <-> kernelspace APIPaul Fertser
NL80211 was introduced in Linux 2.6.24 in 2007 as a new extensible universal API, replacing "wireless extensions" ioctls. It works on top of netlink, and allows direct communication to cfg80211 kernel subsystem. Since then it became a hard requirement for all upstream wireless drivers to hook into cfg80211 (SoftMAC drivers do it via the common mac80211 layer). There's still additional compatibility code that allows limited Wext functionality for cfg80211 drivers but it's buggy and can be disabled altogether when CONFIG_CFG80211_WEXT is not set. This patch makes use of "netlink" Haskell library which doesn't have any additional runtime dependencies (so neither iwlib nor libnl are required). The operation is the same as performed by "iw dev <devname> link" command. The signal level is transformed to "quality" by first clamping it to [-110; -40], then adding 110 and dividing by 70 (same meaningless formula as used by the cfg80211 Wext compatibility layer). "essid" template argument is replaced by more appropriate "ssid" (with the old variant still available for backwards compatibility)
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-22Refactor code from tenthSeconds to doEveryTenthSecondsTomas Janousek
A preparation for timer coalescing: tenthSeconds is just a sleep whereas doEveryTenthSeconds enables using a central timer and waiting for all monitors to update before refreshing the window. This commit is just a simple refactor, the actual timer coalescing code comes later.
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') | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2020-02-11Battery: fix time calculations on some Linux systemsPaul Fertser
The calculations are based on the assumption that current_now (or power_now) are always positive. However, power_supply documentation in the kernel sources say nothing about it, and so some drivers provide a signed value (e.g. bq27xxx_battery_current). Discovered and fixed on ac100/paz00 netbook.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-14 13:23:50 +0000