| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 12 days | add notify-once script and documentation | Léana 江 | |
| 2026-03-08 | Improve `PacmanUpdates` | Enrico Maria De Angelis | |
| 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-28 | Remove deprecated ArchUpdates plugin | Enrico Maria De Angelis | |
| 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-12-24 | Remove unnecessary `extensible-exceptions` dependency | konsumlamm | |
| 2025-06-07 | changelog and version bump | jao | |
| 2025-06-07 | bump base dependency | paumr | |
| 2025-06-04 | MPD compilable again by default with all_extensions | jao | |
| 2025-04-14 | feat: add new PacmanUpdates plugin | Alexander 'ccntrq' Pankoff | |
| the new PacmanUpdates plugin behaves similar to the ArchUpdates plugin while additionally allowing to pass in a custom error message for unknown pacman failures. The default error message of `pacman: Unknown cause of failure.` of the ArchUpdates plugin is too long for my taste. The ArchUpdates plugin was modified to delegate to the new PacmanUpdates plugin while providing the default error message and to show a deprecation notice in the zero updates case. The new name better represents the Plugin's compatibility with all pacman-based distributions, not just Arch. The docs have been updated to reflect the existence of the new plugin and to highlight the similarities between the ArchUpdates and PacmanUpdates plugins. The ArchUpdates plugin has been marked has deprecated there to. | |||
| 2025-04-01 | relax bounds on `base` to allow building with `base v4.20` | Alexander 'ccntrq' Pankoff | |
| 2024-06-21 | Accordion: a plugin two wrap other plugins and collapse them to a single ↵ | Enrico Maria De Angelis | |
| replacement string | |||
| 2024-05-21 | changelog and doc nits for ArchUpdates | jao | |
| 2024-05-18 | ArchUpdates | Enrico Maria De Angelis | |
| 2024-05-07 | changelog and cabal file for 0.48.10.48.1 | jao | |
| 2024-04-01 | version bump | jao | |
| 2024-03-30 | Add ctor for Locks plugin to accpet on/off labels | Enrico Maria De Angelis | |
| 2024-03-21 | changelog &co. for kbd monitor | jao | |
| 2024-02-18 | battery: spawnCommand instead of system when running actions0.47.4 | jao | |
| should fix for real #688 this time | |||
| 2024-02-07 | version tag and changelog0.47.3 | jao | |
| 2024-02-05 | actions: spawnCommand instead of deprecated system | jao | |
| This should address the problems reported in issue #688 | |||
| 2024-01-31 | Bump base dependency | Vekhir | |
| Builds and tests fine | |||
| 2024-01-31 | Add `with_shared` flag to build using shared libraries | Vekhir | |
| Adds the `with_shared` flag, which is off by default. Setting the new flag enables building with shared libraries. By default, `xmobar` is built with static linking. | |||
| 2023-11-12 | fix: dependendecy on mtl to allow GHC 9.60.47.2 | jao | |
| 2023-11-12 | fix: dependendecy on base to allow GHC 9.6 | jao | |
| 2023-11-11 | compatibility with GHC 9.6 | jao | |
| 2023-09-01 | allow requesting explicitly libmpd with with_mpd for any ghc version | jao | |
| 2023-08-30 | version bump | jao | |
| 2023-08-28 | exclude libmpd for ghc 9.4 or greater | jao | |
| 2023-01-05 | testing with ghc 9.2 for now | jao | |
| pango seems to be incompatible with ghc 9.4.4 because it needs text < 2. | |||
| 2023-01-05 | trying to fix deps for ghc 9.4.4 | jao | |
| 2023-01-05 | base 4.17 (ghc 9.4.x) and version bump | jao | |
| 2022-09-30 | Run.Parsers -> Config.Template | jao | |
| 2022-09-20 | new namespace: Xmobar.Draw | jao | |
| 2022-09-19 | cairo: non-cairo is not an option | jao | |
| 2022-09-18 | whitespace | jao | |
| 2022-09-17 | testing CI flags usage | jao | |
| 2022-09-16 | cairo: outer boxes fixes | jao | |
| 2022-09-16 | linting and version bump | jao | |
| 2022-09-15 | new flag: with_xrender | jao | |
| 2022-09-15 | cairo: flags: with_xft gone and with_cairo true by default | jao | |
| 2022-09-12 | X11.MinXft not needed anymore | jao | |
| 2022-09-12 | cairo: with_xft deprecated, with_cairo synomym | jao | |
| 2022-09-11 | fix for the default, non-cairo build | jao | |
| 2022-09-11 | cairo: alpha (still pseudo, via xrender) | jao | |
| 2022-09-10 | cairo: fonts, offsets, colors, actions | jao | |
| 2022-09-09 | cairo: drawing skeleton from an xlib cairo surface | jao | |
| 2022-08-10 | changelog and version bump0.44.2 | jao | |
| 2022-08-09 | examples -> etc | jao | |
| 2022-08-09 | whitespace: deps sorted in xmobar.cabal | jao | |
| 2022-07-12 | Prepare dummy 0.44.1 release to mark transition to codeberg | jao | |
| 2022-07-12 | jao/xmobar -> xmobar/xmobar | jao | |
 |
index : xmobar | |
| a minimalistic status bar | jao |
| summaryrefslogtreecommitdiffhomepage |
path: root/xmobar.cabal