Show on invocation

[avidseeker]

echo 50 | xob

results in bar showing for a split second then disappearing. Adding timeout flag is indifferent.

I don't need xob to be listening all the time for some change. I just want it to "show on demand".

[juster-0]

That's not problem of xob. Process echo 40 finishes faster, so xob is killed before any information can be shown, but you can use sh -c "echo 40; sleep 10" | xob -t 0 and change sleep time for the same effect. Now the first command runs longer and xob can show the information.

[avidseeker]

This works, but is it possible to add "sleep" functionality into xob?

[florentc]

You seem to be looking for a way to display the bar only on demand, when you trigger it, and "sleep" between two events.

This is already how xob and the workflow described in the README (especially the "named pipe" method) are designed.

You say you don't want xob to be "listening all the time". xob is put on hold by the system, "sleeps", until some new data is provided on the standard input. It is not "busy waiting", it does not consume any cpu. How long you want the bar to remain visible after each update is specified by the -t command line argument.

It seems you want a new xob process to be created at each update. This does not bring any upside compared to a persistent xob process waiting for new input. Worse, all the X initialization is done from scratch every time you launch xob, while it is done only once with a persistent xob process.

[avidseeker]

Thank you for clarifying. This indeed seems more efficient. Is it possible to pass arguments to /tmp/xobpipe?

[florentc]

I am not sure I get what you mean by "arguments" regarding the named pipe. What would you like to do?

[avidseeker]

Command line arguments, like xob -s somestyle.

Say I have two styles one for audio and other for brightness.

1. Is it possible to have something like echo 30% -audio >> /tmp/xobpipe or do I have to make two separate pipes for this? /tmp/xobaudio and /tmp/xobbrightness
2. Ok, in this case, is it possible within the audio pipe to tell xob to change appearance? for example, I want pressing mute to change appearance of xob.

I agree initiating xob on every invocation is inefficient, but I'm still doubtful about pipes being the best implementation.

I wonder how other applications: dwmblocks, i3bar, notify-send handle this. They have a straightforward piping interface rather than "writing to pipe file" interface.

If xob has a direct piping interface this would be as easy as

pamixer --get-volume-human | xob -s audio
brightnessctl -m | cut -d"," -f4 | xob -s bright

[florentc]

1. You have to make two separate pipes and xob processes (probably set up to different appearances to distinguish the volume and the brightness bar).
2. Absolutely. Look at the gif animation at the beginning of the README, at some point the bar becomes grey. This is the alternative style, or mute style. Instead of feeding a simple value such as 53, append a bang at the end: 53!. This will display it using the alternative style. The example audio script in the README already makes use of this. By the way, I strongly recommend using an input script instead of doing everything by hand with a named pipe. It is easier (no need to config anything on keypresses) and less error prone. If you don't like using python, a user has suggested shell script instead in issue #44

About the design choice, xob is designed to do only what it is supposed to do (a bit like the suckless.org projects): display a bar. The values it displays are the input, hence, they are read from the standard input. These values are provided by another program such as a volume listener. The simplest way to transmit data from one process to another is the pipe. The inter process communication involved in an xob setup is so basic that it hardly justifies using advanced libraries. Pipes are easy to setup, understood by most users, and easy to tweak.

The recommended method is to use an input script: input-script.sh | xob. The named pipe method is there as a fallback method for users who cannot or do not want to use an input script.