| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- 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.
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Previously, xmobar would ignore SIGCHLD, but only when the configuration
is recompiled. This means child processes would not leave zombies, so
that waiting for them to exit (either directly by calling
waitForProcess, or indirectly through another function from
System.Process, like system or readProcessWithExitCode) would produce an
error. This breaks the Alsa, Com (#657) and NotmuchMail plugins, as well
as the <action> tag (#687) and low battery action (#688).
As far as I can tell, bracketing the recompilation in
uninstallSignalHandlers and installSignalHandlers was inherited from
xmonad. In xmonad, SIGPIPE and SIGCHLD are always ignored
(installSignalHandlers is called at the start of xmonad and launch), so
the bracket is necessary to be able to wait for the compiler or build
script to exit. Since xmobar does not otherwise ignore the signals, it
is not necessary to change signal handlers at all during recompilation.
Removing it leaves the default action for SIGCHLD, which fixes the
issues described above.
Fixes #657, #687 and #688.
|
|
This effectively reverts c54d93e and 991a168. While those fix #687 and
#688 respectively in the case where the configuration is recompiled, in
all other cases they leave zombie processes, since they undo the fix for
#181.
However, instead of reverting to the deprecated system function, we use
the newer spawnCommand and waitForProcess. And like with 991a168, the
low battery action now runs in the background to avoid blocking the bar.
|
|
|
|
|
|
should fix for real #688 this time
|
|
This should address the problems reported in issue #688
|
|
Haskell libraries can be linked statically or dynamically. Either way, all packages must be linked the same way. This means that if all dependencies of `xmobar` are shared libraries, then `xmobar` itself must be built using dynamic linking.
Therefore, to compile the individual `xmobar` executables, add the `-dynamic` flag to signal that they are built with shared libraries.
This flag is put behind an #ifdef to easily configure static vs dynamic linking.
To use shared libraries, define SHARED_LIBRARIES
|
|
|
|
|
|
|
|
Extends the solution from 8a53271cd6 to also handle SocketError, so that the process will not terminate. See also issue #537.
|
|
|
|
|
|
|
|
|
|
Might help with #655
|
|
|
|
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>
|
|
|
|
|
|
|
|
should make things better for #650 and #655
|
|
|
