| Age | Commit message (Collapse) | Author |
|---|
|
The README claimed a minimum supported version of GHC 8.4.x, but that no
longer matched reality. While fixing the GHC < 9.8 build issues in #781
I checked which versions xmobar actually builds with, and the oldest
that succeeds is 9.2:
- GHC 8.4/8.6 fail because colour-2.3.6 requires base >= 4.13 (i.e.
GHC >= 8.8).
- GHC 8.8/8.10/9.0 fail because Xmobar.Plugins.Accordion uses GHC APIs
they lack (withFileBlocking, hGetContents').
Rather than add compatibility shims to keep claiming support for
versions upstream itself no longer recommends, #784 settled on a
simpler, sustainable policy: officially support only the GHC versions
upstream marks as `Suitable for use` in the GHC status overview
(https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-Status). At the time of
writing that means 9.6 through 9.14.
This commit implements that policy:
- Bump the lower bound on base to >= 4.18 (GHC 9.6) so the build
constraints match the documented support, instead of silently
failing on older compilers.
- Document the policy and the current 9.6-9.14 range in the README,
replacing the stale 8.4.x note.
Users who need older GHC versions can continue to use older xmobar
releases.
|
|
|
|
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).
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
replacement string
|
|
|
|
|
|
|
|
|
|
|
|
|
|
should fix for real #688 this time
|
|
|
|
This should address the problems reported in issue #688
|
|
Builds and tests fine
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pango seems to be incompatible with ghc 9.4.4 because it needs text < 2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
