summaryrefslogtreecommitdiffhomepage
path: root/changelog.md
AgeCommit message (Collapse)Author
2022-05-11changelog for 0.430.43jao
2022-04-18CpuFreq: new template parameters max, min and avg.jao
Fixes #166.
2022-04-18New dbus signal: SetAlpha (fixes #499)jao
2022-04-18readme/changelog for Batt fixesjao
2022-04-14Memory: new argument to scale usage unitsjao
Fixes #624
2022-04-12Changelogjao
2022-03-30Changelog and version bumpjao
2022-03-30Load: new load average monitorjao
Closes #208
2022-03-01examples and changlog updated0.42jao
2022-02-18Changelog updatesjao
2022-02-08Documentation bits and version bumpjao
2022-02-03Documentation updatesjao
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. :-)