xmobar/src/Xmobar/Plugins/Monitors, branch mastera minimalistic status barhttps://jao.io/cgit/xmobar/atom?h=master2026-06-26T19:59:27Zremove " &" and fix zombie processes2026-06-26T19:59:27ZLéana 江leana.jiang+git@icloud.com2026-06-16T13:54:22Zurn:sha1:5513b9100728c08789fb19d8cfc314a2c8dab876
" &" was to avoid throwing an exception when the child process has a
non-empty exitcode. However, the error-throwing function is callCommand
and not spawnCommand, so removing " &" shouldn't change the semantic.
https://codeberg.org/xmobar/xmobar/pulls/698#issuecomment-1722323
> callCommand seems to be the closest new function to system, but there
> is a difference: it raises an exception if the child process has a
> non-zero exit code. To preserve the exact behavior would require
> something like spawnCommand (s + "&") >>= waitForProcess.
I was able to reproduce zombie processes with the following steps:
+ running my own xmobar configuration
+ spawning a command that is long running (sleep 10)
+ sending SIGTERM to the xmobar process
After doing so, the sleep command will continue to run.
This PR uses withCreateProcess, which will always wait for the process
to terminate, even when the main thread is asked to exit (SIGTERM).
Note that SIGKILL is not expected to terminate the children.
use Int instead2026-06-23T19:41:59ZLéana 江leana.jiang+git@icloud.com2026-06-22T19:53:40Zurn:sha1:437523ebc951438bc5f0641005f9cfbb6f820e3epass remaining battery percentage to low battery command2026-06-23T19:41:59ZLéana 江leana.jiang+git@icloud.com2026-06-22T15:18:41Zurn:sha1:dcfbeabc8c6c3a775c946fb83628889d254aba48guard low battery alert behind heuristics2026-06-22T14:42:02ZLéana 江leana.jiang+git@icloud.com2026-06-22T14:42:02Zurn:sha1:1d11e75205e25dab4869205a0a05178340d24aff
Previously low battery alerts only depend on the ac variable.
The ac state that is rendered (racst) follows more heuristics. However
this causes a discrepancy where xmobar can show the status is charging
while continue to spawn low battery alerts.
This PR fixes that by using the rendered ac state to decide whether the
alert is sent.
Fix Brightness plugin - fix #7752026-05-29T20:30:43ZEnrico Maria De Angelisenricomaria.dean6elis@gmail.com2026-05-21T22:00:27Zurn:sha1:5077b585ce6e5e2521ef0ef072f038ec5821b6eeRemove unnecessary `extensible-exceptions` dependency2025-12-24T22:17:26Zkonsumlammkonsumlamm@gmail.com2025-12-24T22:17:26Zurn:sha1:50ed21ea8cde2402d8ed139eb0c63f23826f1b1aMPD 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