| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
This should address the problems reported in issue #688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is needed for the plugin to parse properly in non-Haskell based
configurations.
Related: https://github.com/jaor/xmobar/issues/547
|
|
programmatically
|
|
|
|
hGetLineSafe is always hGetLine and hence we can directly use it.
|
|
The first implementation assumed all timers (monitors) are fast and
frequent (which happens to be the case in my configuration). This meant
that a single on-line weather monitor could block the entire xmobar
instance for a long time due to the refresh pausing (meant to reduce
power consumption).
This commit attempts to fix that by limiting the refresh pause time and
using the old periodic sleep method for these slow timers (monitors).
|
|
xmobar currently runs every monitor in its own thread. Monitors that do
periodic updates simply sleep and loop. This unfortunately leads to
these threads coming out of sync, and xmobar ends up waking up and
redrawing for every periodic monitor. In my case, that is 7 times per
second, which is enough for xmobar to be at the top of "top" with more
than 1% CPU usage, and to have a noticeable impact on battery life.
This commit adds a central timer coordination thread which makes sure
that periodic updates happen together and that we only redraw once
they're all done.
Together with PR #409, I managed to lower the idle power draw of my
laptop from 4W to 3W.
|
|
A preparation for timer coalescing: tenthSeconds is just a sleep whereas
doEveryTenthSeconds enables using a central timer and waiting for all
monitors to update before refreshing the window. This commit is just a
simple refactor, the actual timer coalescing code comes later.
|
|
|
|
|
|
|
|
|
|
|
|
|
