Avoids a race where the pipe could be inherited by another process
spawning at about the same time. If the other process didn't exit
quickly (e.g. if it was a custom script that did its own looping), it
would keep the write end of the pipe open, and so reading from the pipe
to try to get the command's output would block.
This bug manifested as some custom modules randomly not appearing in the
bar, requiring a reload to fix. The custom script had run and exited,
but the pipe had been inherited by another process, and the thread that
updated the module's output was blocked trying to read from it.
some users (maybe only myself) may want to sort the task bar by app_id
which then places occurrences of the same task next to each other.
Signed-off-by: Louis DeLosSantos <louis.delos@gmail.com>
In order to fix the issue, the default node name is cached rather than
the default node id. This is due to ids being unstable. So now when the
object manager is installed (ie ready), the default node name is
retrieved and stored for later.
Now when the mixer changed signal is emitted, the id of the changed node
is used to get the node from the object manager. The nodes name is
grabbed off that node and compared against the default node name, if
they match the volume is updated. Some safeguarding has been added such
that if the node cannot be found off the object manager, it's ignored.
Additionally, the "changed" signal on the default nodes api is now
utilized to update the default node name if it has changed. This way if
the default node changes, the module will be updated with the correct
volume and node.nick.
This adds additional debug logging for helping diagnose wireplumber
issues.
This also adds the wireplumber man page entry to the main waybar
supported section.
