summaryrefslogtreecommitdiffhomepage
path: root/readme.md
AgeCommit message (Collapse)Author
2020-11-18changelog linkjao
2020-11-18Nitsjao
2020-11-18clean-ups for web page generationjao
2020-11-18Wee tidy-upsjao
2020-11-18More readme clean-upsjao
2020-11-18Link fixjao
2020-11-18Readme imagesjao
2020-11-13Another image in readme.mdjao
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-10-24Adding example xmobar library install with cabalMark Watts
- Relates to #491
2020-10-09Changelog and friendsjao
2020-10-09update readme: -N --add-font optionivanbrennan
2020-08-09Doc fixesjao
2020-08-09A bit more documentation for <box>jao
2020-08-09readme tweaksjao
2020-08-09A bit of documentation for <box>jao
2020-08-07Switch from Travis to Github actions (#480)jao
2020-08-07revert broken indents on readmeUnoqwy
2020-08-07remove outdated <box> docUnoqwy
2020-08-07readme: box default valuesUnoqwy
2020-08-07readme: update fc tag and add boxUnoqwy
2020-08-07String index as progress barjao
2020-07-23readme: Document escaping in UnsafeStdinReaderTomáš Janoušek
2020-07-22readme: Fix duplicated NamedXPropertyLogTomáš Janoušek
2020-06-27License file updatedjao
2020-06-27Readme headersjao
2020-06-26readme.org indexjao
2020-06-13Version bump, changelog, readmejao
2020-06-13Detection of Tdie and Tctl for Ryzen temperaturesjao
2020-05-06fix readme typoPeter Becich
2020-04-30author's list update (sibi)jao
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-03-05Network: up indicatorjao
2020-02-26Copyright yearsjao
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-05Update changelog and readmeslotThe
2020-02-04fix --high to --highs in documentationToni Tauro
2020-01-08Changelog and creditsjao
2020-01-05Update readme and changelogslotThe
2020-01-04Doc nitsjao
2020-01-04Update readme and changelogslotThe
2019-12-23Add support for the "Weather" fieldslotThe
2019-12-08Change log0.32jao
2019-11-14MPD monitor: host and port specifiable in configjao
2019-10-21add filtering option for Net devices (#408)vindex10
* add filtering option for Net devices * relate to comments * upd readme * add few more words to readme
2019-10-15Battery: -P to show %jao
2019-10-15New plugin: MailXjao
2019-10-14Update readmeslotThe
2019-10-12Update changelog and readmeslotThe
2019-10-12Docs formatjao
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-05 00:49:41 +0000