xmobar/src/Xmobar/Plugins, branch 0.50a minimalistic status barhttps://jao.io/cgit/xmobar/atom?h=0.502025-06-04T03:27:56ZMPD compilable again by default with all_extensions2025-06-04T03:27:56Zjaojao@gnu.org2025-06-04T03:27:25Zurn:sha1:404073416c5f97ab8b82aa436b4f862d349c0dadswap_enabled is not accessable in FreeBSD 15/Current2025-06-02T18:45:12ZMichal Zielonkamichal.zielonka.8001@gmail.com2025-06-02T13:36:29Zurn:sha1:146d85af8b54d8e346adcde9eb02917138172145
instead of swap_enabled in top program currently checking number of
swap devices is used.
Accordion: new constructor to allow short version to have plugins too2025-06-01T11:05:07ZEnrico Maria De Angelisenricomaria.dean6elis@gmail.com2025-06-01T11:05:07Zurn:sha1:853326b3c2a0034af79dedf6934b3b67734ef98aAccordion: some renaming and reformatting2025-06-01T10:04:25ZEnrico Maria De Angelisenricomaria.dean6elis@gmail.com2025-06-01T10:04:25Zurn:sha1:49a9bfe9a138dd43ab213255a0130b222ba2acc3feat: add new PacmanUpdates plugin2025-04-14T14:21:30ZAlexander 'ccntrq' Pankoffccntrq@screenri.de2025-04-10T06:20:15Zurn:sha1:82398b1603d139898be70af97ef9d59ba441bae0
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.
hlinting2025-03-31T16:02:58Zjaojao@gnu.org2025-03-31T16:02:58Zurn:sha1:98857472d93e6c6b4c9d501ae5c7172874c1ed82mpris: Read track length from Word64 too2025-03-31T15:07:22ZClaudio Bleyclaudio.bley@gmail.com2025-03-31T15:07:19Zurn:sha1:c6976e852e4c9a8cd590c1c87eb6d7d9c6ce23c0
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
fallback to weather in weatherS2024-08-26T20:41:54Zjaojao@gnu.org2024-08-26T20:41:54Zurn:sha1:4e8ec5a4c86873018f3ba33669fb9affff280d6ewee refactoring2024-08-25T16:58:27Zjaojao@gnu.org2024-08-25T16:58:27Zurn:sha1:3500eb6c7ba57fd2ce32f89fdde6edd6918679f9new template variable weatherS for WeatherX2024-08-25T16:47:30Zjaojao@gnu.org2024-08-25T16:47:30Zurn:sha1:0c4daf1bcb9373479ac99767ee0dcb649e248f25