a minimalistic status bar https://jao.io/cgit/xmobar/atom?h=master 2026-03-11T11:39:18Z 2026-03-11T11:39:18Z Enrico Maria De Angelis enricomaria.dean6elis@gmail.com 2026-03-11T11:39:18Z urn:sha1:70f8a6374b269669362cf04c576b6990e842c108 2026-03-09T09:07:19Z Enrico Maria De Angelis enricomaria.dean6elis@gmail.com 2026-03-09T09:00:30Z urn:sha1:0805ea0b8c06a6b1a97f226b87489c38fc3a9d01 This is a minor follow up to https://codeberg.org/xmobar/xmobar/pulls/764, so see that one as well if you got here because the plugin told you it's deprecated. This change consists of: - turning the deprecated constructor in a pattern synonym for the new ones (which are also pattern synonyms for calling convenience), - dropping the `PacmanUpdatesDeprecated` type entirely, - adding documentation with usage examples. 2026-03-08T17:56:49Z Enrico Maria De Angelis enricomaria.dean6elis@gmail.com 2026-03-06T16:10:10Z urn:sha1:508feb2abf27ea991bbcc0ba163e3f64cd60b67b Recently, I've seen the usefulness in knowning whether one of the pending updates is a kernel update (which means we should most likely reboot after next system update), and also whether the running kernel is older than the installed kernel package (which means we've probably not rebooted yet), so I thought I should update this plugin. However, the feature of knowing whether a kernel update is contained in the available updates requires that one knows the kernel package name, so that's to be a `String` input to the plugin. But one might not want to pass it, and be happy with just the detection of whether the running kernel is older than the installed one. Since recently, I've been studying type families and also come across pattern synonyms, I thought I could leverage these, so I thought I could parametrize the plugin over kind `Bool`, and branch on it to provide the different APIs; then I could use type synonyms to lift the burden of having to use type application at the user code. Furthermore, rather than still customizing the message by asking the user to provide `String`s for the various cases (0 updates, 1 update, 2+ updates), I thought it was better to ask the caller to provide a function that accepts the relevant inputs (`Int` number of updates, `Bool` telling whether such and such) and turns them into a `String`. With this change, I'm - renaming the previous type `PacmanUpdates` to `PacmanUpdatesDeprecated` - deprecating such type (with a pragma and by printing a clickable note in the plugin text) with the intention of deleting it in a year from now, - preserving its data ctor's to avoid breaking existing code right now, - creating a new `PacmanUpdates` type that is parametrized over kind `Bool` - the `True` instance allows passing the name of the kernel package that the plugin uses to detect whether there's a pending kernel update - the `False` instance doesn't, - accordingly the two instances accept from the caller a printing function with different signature (see haddock comments for details), - hiding (i.e. not exporting) the constructor of such new type, - provided pattern synonyms to more conveniently create a `PacmanUpdates False` (for `PacmanUpdates True` is just the same as the ctor), - changing the approach with which the final `String` is produced, from asking the user to provide a bunch of some sort of template `String`, to asking them for a function that produces a `String` given the required inputs (e.g. the number of available updates). 2026-02-28T08:05:11Z Enrico Maria De Angelis enricomaria.dean6elis@gmail.com 2026-02-28T07:51:16Z urn:sha1:39fd70308c3aef5402abe7152ade76ff7bb331bb Users should have long switched to PacmanUpdates, as communicated in #723. Furthemore, we had forgotten to list PacmanUpdates in the plugins wrappable in Runnable. Fixed now. 2025-10-26T12:16:59Z Enrico Maria De Angelis enricomaria.dean6elis@gmail.com 2025-10-26T11:06:21Z urn:sha1:0495a8c0e453b0d29e3eb24f38491a9d534c5e94 2024-05-18T14:19:42Z Enrico Maria De Angelis enricomaria.dean6elis@gmail.com 2024-04-17T17:25:45Z urn:sha1:80be37611711871c6971588873687755103097c0 2024-03-30T18:26:01Z jao jao@gnu.org 2024-03-30T18:26:01Z urn:sha1:30d226ba5eca8847775d03403367dee1f1e3dcfc 2024-03-30T14:42:03Z Ulrik de Muelenaere ulrikdem@gmail.com 2024-03-30T14:42:03Z urn:sha1:9349871b9eb888d1d1b7f552ea40f8d348b16c1b This effectively reverts c54d93e and 991a168. While those fix #687 and #688 respectively in the case where the configuration is recompiled, in all other cases they leave zombie processes, since they undo the fix for #181. However, instead of reverting to the deprecated system function, we use the newer spawnCommand and waitForProcess. And like with 991a168, the low battery action now runs in the background to avoid blocking the bar. 2024-02-05T18:31:27Z jao jao@gnu.org 2024-02-05T18:31:27Z urn:sha1:c54d93e6d4d6c0d194bcd8696dce92da9f795869 This should address the problems reported in issue #688 2022-09-30T05:50:53Z jao jao@gnu.org 2022-09-30T05:50:53Z urn:sha1:ef380c045957413948d390c152f6401869526285