summaryrefslogtreecommitdiffhomepage
path: root/changelog.md
AgeCommit message (Collapse)Author
2022-02-01Documentation bitsjao
2022-01-01Changelog update0.41jao
2021-12-17changelog/versionjao
2021-11-05changelog0.40jao
2021-10-19changelog (michal)jao
2021-10-11changelogjao
2021-10-05Changelogjao
2021-09-15Changelog and whitespacejao
2021-08-13readme and changelog0.39jao
2021-08-12changelog updatedjao
2021-07-13changelogjao
2021-07-12Add TopH and BottomH for only controlling height of the window. (#556)Joan MIlev
2021-07-06Changelog: mention of new CLI args handlingjao
2021-06-18Fix MultiCoreTemp --hwmon-path argument docsSebastian Nagel
2021-05-24changelog updatesjao
2021-05-21changelog and authorsjao
2021-05-19Version 0.380.38jao
2021-05-14Fix delayed reaction to USR1/2 signalsTomas Janousek
While using xmobar to reproduce/fix a bug in xmonad I noticed that xmobar doesn't react immediately to the signals to reposition or change screen. Apparently none of the Xlib functions called from `repositionWin` flush the Xlib output buffer (XMoveResizeWindow is known to not flush, although it's unfortunately not documented), so when compiled with the threaded runtime that runs XNextEvent in a separate thread, the reposition is sent to the X server only later when other stuff happens. With all monitors set to refresh once a minute, this can take a looong time. (It's entirely possible this happens even without the threaded runtime, I didn't test that, sorry.) The fix is to call XSync at the end of `repositionWin`. While at it, I spotted that drawInWin calls XSync with discard=true, which seems like a mistake. We don't want to discard any events, do we? (In practice, I'd expect the `eventer` thread to read all events even before the drawing thread manages to discard them, so even if this discarding XSync ever had any reason to be there, I don't think it does anything meaningful these days. I may be wrong, though.)
2021-04-27Revert "Conditional encoding …" and "Avoid double utf8 encoding" (#482)Tomas Janousek
This reverts commits c6669e26e1 (partially; changelog entry kept), 73e02934d6, 78efa5900a. These commits were introduced as a workaround for a double UTF-8 encoding bug in xmonad-contrib which itself was meant to be a fix/workaround for another issue. We have now identified the underlying issue and fixed it right at the root, so this entire cascade of hacky (and wrong) workarounds can be safely reverted. Thankfully, none of the xmonad-contrib hacks made it into a release, so there's no backward compat to worry about. Should anyone be interested in the details, https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788 provides a summary and links to all the related issues and PRs. Related: https://github.com/jaor/xmobar/pull/482 Related: https://github.com/jaor/xmobar/issues/476 Related: https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788 Related: https://github.com/xmonad/xmonad-contrib/pull/471 Related: https://github.com/xmonad/xmonad-contrib/issues/377
2021-04-27Changelog update (#538, #530)Tomas Janousek
2020-11-290.370.37jao
2020-11-29Update readme and changelogslotThe
2020-11-24New monitor: MPDXjao
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-08Changelog entry for Revert "Optimize date plugin"Tomas Janousek
A missing bit from a58e32f7c8af7b03410ab6693019cfc92c9cfca3.
2020-10-09Changelog and friendsjao
2020-08-220.360.36jao
2020-08-09Update changelog and add commentSibi Prabakaran
2020-08-07Changelog updatesjao
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-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-26Changelog updates0.35jao
Fixes #466
2020-06-13Version bump, changelog, readmejao
2020-06-12Updates for 0.340.34jao
Closes #457
2020-06-12Update changelogSibi Prabakaran
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-04-27Changelog updatedjao
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-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-23Changelog entry for time coalescingjao
2020-02-05Update changelog and readmeslotThe
2020-01-08Changelog and creditsjao
2020-01-05Update readme and changelogslotThe
2020-01-04Doc nitsjao
2020-01-04Update readme and changelogslotThe
2019-12-23Changelog updatejao
2019-12-23Add support for the "Weather" fieldslotThe