| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
" &" was to avoid throwing an exception when the child process has a
non-empty exitcode. However, the error-throwing function is callCommand
and not spawnCommand, so removing " &" shouldn't change the semantic.
https://codeberg.org/xmobar/xmobar/pulls/698#issuecomment-1722323
> callCommand seems to be the closest new function to system, but there
> is a difference: it raises an exception if the child process has a
> non-zero exit code. To preserve the exact behavior would require
> something like spawnCommand (s + "&") >>= waitForProcess.
I was able to reproduce zombie processes with the following steps:
+ running my own xmobar configuration
+ spawning a command that is long running (sleep 10)
+ sending SIGTERM to the xmobar process
After doing so, the sleep command will continue to run.
This PR uses withCreateProcess, which will always wait for the process
to terminate, even when the main thread is asked to exit (SIGTERM).
Note that SIGKILL is not expected to terminate the children.
|
|
|
|
|
|
|
|
|
|
This commits implements a ci workflow for Codeberg's hosted woodpecker
instances that verifies xmobar can be built with the ghc versions we
claim support for. Currently there is a known issue with ghc>9.12.2
(https://github.com/gtk2hs/gtk2hs/issues/348) that's why we don't run
the built with ghc 9.12 and 9.14 until that issue is resolved upstream
Closes: #784
|
|
Previously low battery alerts only depend on the ac variable.
The ac state that is rendered (racst) follows more heuristics. However
this causes a discrepancy where xmobar can show the status is charging
while continue to spawn low battery alerts.
This PR fixes that by using the rendered ac state to decide whether the
alert is sent.
|
|
Bump the resolver from lts-18.20 (GHC 8.10.7) to lts-24.45 (GHC 9.10.3).
GHC 8.10 is below the minimum we now support, so the old resolver no
longer matched our GHC support policy. lts-24.45 sits within the
supported 9.6-9.14 range and is the latest lts on stackage.
The newer snapshot ships recent enough versions of libmpd, cairo, pango,
glib and gtk2hs-buildtools, so drop them from extra-deps and let stack
take them from the resolver.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
