| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
|
|
This reverts commit 0fec9d3fdf9bc86187f9f670dafd2ef57fe03f29.
Mouse actions can already be attached to the monitor, and for instance use
there invocations to setxbdmap to switch layouts.
Fixes #703.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds a new DPI configuration, especially useful for HiDPI displays. This changes the scaling factor for fonts as displayed by Pango. It defaults to 96.0 which corresponds to an average screen and is the default in [Cairo](https://hackage.haskell.org/package/pango-0.13.5.0/docs/Graphics-Rendering-Pango-Cairo.html#v:cairoFontMapGetDefault). It's also possible to supply a zero or negative value to use the default scaling factor, but I felt setting the default to 96.0 makes it more explicit.
It also adds a matching command line option.
I haven't tested it too thoroughly, but in my limited use it appears to be working as intended.
One thing this does not do is scale XBM and XPM bitmap files which I'm unsure how to do or if that should even be our concern (instead leaving it up to the user to supply appropriate bitmaps).
Co-authored-by: Jonathan Grochowski <jon@grocho.net>
Reviewed-on: https://codeberg.org/xmobar/xmobar/pulls/660
Co-authored-by: jgrocho <codeberg@jon.grocho.net>
Co-committed-by: jgrocho <codeberg@jon.grocho.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
