summaryrefslogtreecommitdiffhomepage
path: root/xmobar.cabal
AgeCommit message (Collapse)Author
2022-02-04Xmobar.App.TextEventLoop -> Xmobar.Text.Loopjao
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-04Xmobar.App.Timer -> Xmobar.Run.Timerjao
2022-02-03Xmobar.X11.Actions -> Xmobar.Run.Actionsjao
2022-01-29App.EventLoop -> App.X11EventLoopjao
2022-01-29Basic Xmobar.App.TextEventLoopjao
2022-01-29Xmobar.App.CommandThreadsjao
2022-01-29Xmobar.Run.Command -> Xmobar.Plugins.Commandjao
2022-01-16References to xmobar.org updated (fixes #599)jao
2021-12-17changelog/versionjao
2021-12-17add disk monitor for freebsdMichal Zielonka
2021-10-17start using kvm library from bsd for receiving swapinfoMichal Zielonka
Using this library allows us to receive swap info which is more similar with result of command swapinfo.
2021-10-16add top for freebsd procMichal Zielonka
In FreeBSD /proc/pid/stat is missing we should use for top procstat library.
2021-10-08try to add build action for freebsd + uptime plugin splitMichal Zielonka
2021-10-08try to reorganize modules per osMichal Zielonka
We should make better split os specify code for FreeBSD and Linux. Idea comes from @liskin.
2021-09-15Changelog and whitespacejao
2021-09-14Add the QueueReader plugin.Guy Gastineau
* A queue reader for xmobar using `TQueue a` from `stm`. This is a flexible and performat solution for sharing data between arbitrary haskell and xmobar. * I am not sure if I did the haddocks correctly.
2021-07-14Relax base requirements to allow build with GHC 9.0 (#557)Vladimír Štill
2021-07-13Add Kraken pluginAmir Saeid
2021-05-21changelog and authorsjao
2021-05-19Add k10temp pluginSam Kirby
The existing support for the coretemp kernel driver only works with Intel CPUs. This commit extends support for temperature monitoring to AMD CPUs. k10temp is a kernel driver for monitoring the temperature of AMD processors. It supports everything from AMD's 10h (Opteron/Athlon) family of processors to the latest 19h (Zen 3) family. Reference: https://www.kernel.org/doc/html/latest/hwmon/k10temp.html The meaning of the various temperatures made available has changed over the years and only `Tctl` is available on processors prior to the 17h family. Labels for these temperatures are present but as Tctl and Tdie do not contain a number I could not find a way to use these as `checkedDataRetrieval` expects an integer label. It is a PCI device and so an address needs to be supplied as part of the configuration. Example configuration: `Run K10Temp "0000:00:18.3" ["--template", "T: <Tdie>C | <Tccd1>C"] 60`
2021-05-19Version 0.380.38jao
2021-01-18Expose Xmobar.Plugins.Monitors.Common (fixes #520)jao
Exposing Common.Types and Common.Run is now redundant, but we could break configurations out there, so i'm not sure if we should remove them.
2020-12-20Including new .org doc files in extra-source-filesjao
2020-11-29Add new plugin: NotmuchMailslotThe
This plugin checks for new mail, provided that this mail is indexed by notmuch. As mail that was tagged is moved from the new directory to cur, the 'Mail' plugin (and its variants) won't work for such mail.
2020-11-19test: Fix flaky CpuSpecTomas Janousek
Failed at least once in GitHub Actions: predicate failed on: "Cpu: <fc=red>100</fc>% <fc=red>##########</fc>" Also, there's no need to guard the Xmobar.Plugins.Monitors.CpuSpec module with the with_alsa flag. (And it doesn't really work anyway, hspec-discover doesn't care about what modules are declared in cabal, so stack/ghc complains that "These modules are needed for compilation but not listed in your .cabal file's other-modules: Xmobar.Plugins.Monitors.AlsaSpec" and then fails to detect changes in those modules.)
2020-11-13Optimize Date plugin again (refresh timezone only once a minute)Tomas Janousek
This makes the Date plugin approximately twice as fast, and makes xmobar up to about 5–10 % faster if Date is the only active plugin. (If more expensive plugins like Network or MultiCpu are used, it doesn't make any measurable difference.) Micro-benchmark results on my HW: Date Benchmarks/Date mean 2.833 μs ( +- 16.08 ns ) Date Benchmarks/DateZonedTime mean 5.020 μs ( +- 32.91 ns ) Date Benchmarks/DateWithTimeZone mean 2.827 μs ( +- 20.52 ns ) (DateZonedTime is the original implementation and DateWithTimeZone is the implementation we had since 0.34 which never refreshes timezone.) Real-life measurements (done overnight on an idle laptop, with all measured xmobars running in parallel to ensure comparable conditions; xmobars configured to only display date and with rate 10 — once per second): $ time timeout 6h xmobar .xmobarrc-DateZonedTime real 360m0,010s user 0m9,867s sys 0m4,644s (9.867 + 4.644) / (360 * 60) = 0.000672 $ time timeout 6h xmobar .xmobarrc-Date real 360m0,008s user 0m9,535s sys 0m4,327s (9.535 + 4.327) / (360 * 60) = 0.000642 $ time timeout 6h xmobar .xmobarrc-Date-10m real 360m0,010s user 0m9,780s sys 0m4,215s (9.780 + 4.215) / (360 * 60) = 0.000648 $ time timeout 6h xmobar .xmobarrc-DateWithTimeZone real 360m0,006s user 0m9,658s sys 0m4,166s (9.658 + 4.166) / (360 * 60) = 0.000640 (.xmobarrc-Date-10m is the proposed implementation, but with timezone refresh every 10 minutes instead of every 1 minute) Interpretation of these results: * refreshing xmobar with just date takes around 650 μs * that is xmobar with just date uses around 0.065 % of CPU time * refreshing timezone takes additional cca 30 μs When we only refresh timezone once a minute, these 30 μs become 0.5 μs amortized, and that should be acceptable to even the most dedicated perfectionist :-) Fixes: a58e32f7c8af ("Revert "Optimize date plugin"") Fixes: 878db3908060 ("Optimize date plugin") Co-authored-by: Sibi Prabakaran <sibi@psibi.in>
2020-11-13bench: Clean up a bitTomas Janousek
2020-10-25Fix for broken DateZone monitorDino Morelli
There's a longstanding bug in timezone-olson that causes it to fail to read some zoneinfo files (but not all, oddly). This was resolved in timezone-olson-0.2.0 which can be built against by using a later Stackage snapshot than master currently points to. This fix pushes the snapshot up to lts-16.0 and also modifies the cabal version range for timezone-olson to set 0.2.0 as the minimum.
2020-10-10update libmpd to 0.9.2.0Olivier Schneider
2020-10-09Changelog and friendsjao
2020-08-07Changelog and unreleased version bumpjao
2020-06-26Drop support for GHC < 8.4 (fixes issue #461)0.35.1jao
2020-06-26Version bumpjao
2020-06-23Cleanup and add some testsSibi Prabakaran
2020-06-19Allow building with timezone-olson-0.2.0Peter Simons
Fixes https://github.com/jaor/xmobar/issues/463.
2020-06-13Version bump, changelog, readmejao
2020-06-13Initial support for benchmarks of the pluginsSibi Prabakaran
2020-06-12Updates for 0.340.34jao
Closes #457
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-04-27Base for ghc 8.10 (fixes #440)jao
2020-04-12Version bumpjao
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-12Require bytestring >= 0.10.8.2.Zev Weiss
Version 0.10.8.1 contains a bug in the readFile function that misbehaves on things like magic procfs files where stat(2) returns an st_size of zero, which breaks the Net monitor and such; 0.10.8.2 contains the fix.
2020-03-05Not exposing modules outside Xmobarjao
2020-02-26Version 0.330.33jao
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.