| 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.
|
|
Export-list DEPRECATED pragmas were only added in GHC 9.8 (proposal
`#134`[1]). On older compilers the pragma inside the export list is a
parse error ("parse error on input '{-# DEPRECATED'"), breaking the
build.
Guard the pragma with CPP so it is only emitted on GHC >= 9.8. The
export-list form is kept deliberately: it deprecates only the `pattern
PacmanUpdates` export, leaving the equally-named `PacmanUpdates` type
untouched, so downstream users referencing the type get no spurious
deprecation warnings. On older GHC the compile-time warning is simply
absent; the runtime "deprecated plugin" note still informs users.
[1]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst
|
|
PacmanUpdates previously supported either no kernel update detection or
matching a single kernel package name. That works for Arch's `linux`
package, but not for Manjaro's series specific kernel packages such as
`linux618` or `linux70`.
Replace the Bool indexed API with an explicit kernel check kind and add
`PacmanUpdatesPredicateK`, which accepts a `String -> Bool` predicate for
detecting kernel updates from the package list.
|
|
|
|
|
|
|
|
When alpha is 255 (fully opaque), the pseudo-transparency blend factor
is zero (0xFFFF - 257 * 255 = 0), making the root pixmap composite a
visual no-op. However, drawBackground unconditionally calls
XRenderCreatePicture on the _XROOTPMAP_ID pixmap.
Wallpaper setters like feh free the old root pixmap via XKillClient
each time they cycle to a new image. If xmobar attempts
XRenderCreatePicture on the freed pixmap, the X server returns
BadDrawable and the default error handler terminates xmobar.
Guard the entire root pixmap code path with `when (alpha < 255)` so
that fully opaque bars never touch _XROOTPMAP_ID.
|
|
|
|
|
|
- Use `RecordWildCards` language extension
- Use `concurrently_` and `mapConcurrently_` instead of `withAsync`
- Use `Bool` instead of `Maybe ()`
- Use `whenM` instead of `when`
- Add signature to `loop`
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
instead
|
|
|
|
The reason is that this way the issue
https://codeberg.org/Aster89/xnobar/issues/15#issue-2346829 is fixed.
See https://codeberg.org/Aster89/xnobar/issues/15#issuecomment-7864955
for more details.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
instead of swap_enabled in top program currently checking number of
swap devices is used.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
According to the MPRIS v2 spec, the length of a track "must be given in
microseconds, and be represented as a signed 64-bit integer". [1]
But Spotify does not follow the spec and represents it as an unsigned
64-bit integer:
```
$ dbus-send --session --print-reply --reply-timeout=150 --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.freedesktop.DBus.Properties.Get string:org.mpris.MediaPlayer2.Player string:Metadata
method return time=1743433787.301824 sender=:1.142 -> destination=:1.178 serial=1071 reply_serial=2
variant array [
dict entry(
string "mpris:length"
variant uint64 152000000
)
...
```
This always made the `length` template argument end up empty, but
allowing a Word64 for this attribute fixes this problem.
[1]: https://specifications.freedesktop.org/mpris-spec/latest/Track_List_Interface.html#Mapping:Metadata_Map
|
|
Author: refaelsh <refaelsh@pm.me>
Date: Tue Oct 8 18:14:23 2024 +0100
|
|
|
