xmobar/src/Xmobar/Plugins/Monitors, 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.
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:0c4daf1bcb9373479ac99767ee0dcb649e248f25fix for unmet pattern matches warnings (clean build)2024-03-30T18:26:01Zjaojao@gnu.org2024-03-30T18:26:01Zurn:sha1:30d226ba5eca8847775d03403367dee1f1e3dcfcFix zombie processes left by <action> tag and low battery action2024-03-30T14:42:03ZUlrik de Muelenaereulrikdem@gmail.com2024-03-30T14:42:03Zurn:sha1:9349871b9eb888d1d1b7f552ea40f8d348b16c1b
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.
battery: spawnCommand instead of system when running actions2024-02-18T21:46:07Zjaojao@gnu.org2024-02-18T21:44:54Zurn:sha1:991a168de5d79314a1346a24c579c5049208b054
should fix for real #688 this time