francma / wob

A lightweight overlay volume/backlight/progress/anything bar for Wayland.

wob — Wayland Overlay Bar

A lightweight overlay volume/backlight/progress/anything bar for wlroots based Wayland compositors (requires support for wlr_layer_shell_unstable_v1).

Release signatures

Releases are signed with 5C6DA024DDE27178073EA103F4B432D5D67990E3 and published on GitHub.

Installation

Compiling from source

Install dependencies:

• wayland
• inih
• wayland-protocols *
• meson *
• scdoc (optional: man page) *
• libseccomp (optional: Linux kernel syscall filtering) *
• cmocka (optional: tests) *

* compile-time dependency

Run these commands:

git clone [email protected]:francma/wob.git
cd wob
meson build
ninja -C build
sudo ninja -C build install

From packages

Usage

Launch wob in a terminal, enter a value (positive integer), press return.

wob

General case

You may manage a bar for audio volume, backlight intensity, or whatever, using a named pipe. Create a named pipe, e.g. /tmp/wobpipe, on your filesystem using.

mkfifo /tmp/wobpipe

Connect the named pipe to the standard input of a wob instance.

tail -f /tmp/wobpipe | wob

Set up your environment so that after updating audio volume, backlight intensity, or whatever, to a new value like 43, it writes that value into the pipe:

echo 43 > /tmp/wobpipe

Adapt this use-case to your workflow (scripts, callbacks, or keybindings handled by the window manager).

See wob.ini.5 for styling and positioning options.

Examples

See Contrib space.

Alternatives

• avizo - icons, volume and brightness
• SwayOSD - icons, volume, brightness and keyboard (caps lock, num lock)
• Notification daemon + custom script
• xob - X Overlay Bar - X11 only, inspiration for wob

License

ISC, see LICENSE.

wob's Issues

Release archives are tar instead of gzip

I'm getting strange errors while trying to upgrade wob from 0.8 to 0.10 on my Gentoo machine. After some investigation with file it seems that the .tar.gz in the Release section of versions 0.10 and 0.9 are only TAR files, despite the extension .tar.gz. Version 0.8 was fine and is actually compressed with gzip.
Is it possible that you made a mistake while creating the archives?

Feature request: add rotation option

Something like -r, --rotate=vertical would be nice.

Reloading sway config file does not change aspect of bar

Previously I had configured wob with default settings (just like in the sway example in README)

However when I changed this line
exec mkfifo $WOBSOCK && tail -f $WOBSOCK | wob
to
exec mkfifo $WOBSOCK && tail -f $WOBSOCK | wob -a top
reloaded sway, no changes were made.

New release

a new release would be nice

socket running, but doesn't work

Heya, I just installed wob and set and editted the config file, copied the files into .config/systemd/user/ as the location given in repo said

systemctl --user list-units | grep wob
  wob.socket                                                                                    loaded active listening wob.socket

But it's not working, How do I check what's the error?

Coloring interpretes alpha value in an unexpected way

System: Debian GNU/Linux testing/unstable
Sway Version: 1.4 (from Debian repository)
wob Version: 7d03efc (compiled from this repository)

I tried to integrate the coloring of wob into my overall theme and saw that the same color codes (swaybar's #rrggbbaa rewritten to wob's #aarrggbb format) were rendered differently, but only if the alpha value was lower than ff. More testing shows that only the "black part" of the color will be made transparent.

An example: The "colors" #00000000 and #00ffffff (#aarrggbb) should both be transparent in the same way because both have an alpha value of 00. However wob renders the first one fully transparent (as expected), but the second one fully white (not as expected). To test this yourself, run following commands:

# cd into the build directory of the repository
# Correct transparent rendering
echo 50 | ./wob -t 3000 --border-color '#00000000' --bar-color '#ff00ff00' --background-color '#00000000'
# Incorrent transparent rendering
echo 50 | ./wob -t 3000 --border-color '#00000000' --bar-color '#ff00ff00' --background-color '#00ffffff'

Sometimes wob fails with working settings

Sometimes wob fails even though the settings are correct. This happens only sometimes and only when I change an argument. The next run with the same settings works fine.

tail -f /run/user/1000/sway-ipc.1000.1694.sock.wob  |
    wob --border-color=#ffaa0000 \
        --background-color=#77000000 \
        --bar-color=#ffaa0000 \
        --output=\* -v -W 400 -H 20 -o 0 -p 0 --border=3
1596892275.917285 ERROR main.c:571: Border color must be a value between #00000000 and #FFFFFFFF.

Option `--output \*` doesn't display on all displays when multiple monitors are connected (Sway)

In my Sway config, I run a script that includes the line tail -f /tmp/wobpipe | wob -O \* &

When I output to /tmp/wobpipe nothing is displayed on my two main monitors. For reference, I'm using a laptop with two external displays connected. The laptop display is disabled.

I have confirmed that the pipe does exist and is being written to.

I have fixed the issue by adding a sleep 1 to the beginning of my script. I believe that the issue might have something to do with the displays not being initialized when Sway first starts, and that's why sleeping for one second before starting wob fixes the issue.

Suggested wrapper script

This script makes 'wob' easier to set up - eg without needing a clause in sway's config file. As a plus, it's self healing - if 'wob' dies for some reason, it is re-started on demand.

Usage is simply:

mywob 51

Here's the essence of the script:

#!/usr/bin/env bash

new_value=$1 # null or a percent

wob_pipe=~/.cache/$( basename $SWAYSOCK ).wob

[[ -p $wob_pipe ]] || mkfifo $wob_pipe

pkill -0 wob || {
    tail -f $wob_pipe | wob &
}

case $new_value in
    "")
        :
        ;;
    *)
        echo $new_value > $wob_pipe
        ;;
esac

Wob accepts invalid input.

While fiddling around with the code for a pull request I'm working on I noticed that some input outside the range of 0-100 is accepted by wob.

For example most values between 256 and 299 is accepted by wob. 300 is not accepted but 512 and some other numbers are accepted.
299 is displayed as roughly 45% for instance.

Cannot set border background or bar color with wob 0.10

Hi I am using wob under arch linux. Wob is version 0.10.

When typing for instance :
$ tail -f ~/.config/wob/testwob | wob --border-color FF1793D1

Output is :
1605374475.959878 ERROR main.c:571: Border color must be a value between #00000000 and #FFFFFFFF.

with an hash on the aarrggbb color :

$ tail -f ~/.config/wob/testwob | wob --border-color #FF1793D1

Output is :
wob: option '--border-color' requires an argument
Usage: wob [options]

-h, --help Show help message and quit.
--version Show the version number and quit.
-v Increase verbosity of messages, defaults to errors and warnings only
-t, --timeout Hide wob after milliseconds, defaults to WOB_DEFAULT_TIMEOUT.
-m, --max <%> Define the maximum percentage, defaults to WOB_DEFAULT_MAXIMUM.
-W, --width Define bar width in pixels, defaults to WOB_DEFAULT_WIDTH.
-H, --height Define bar height in pixels, defaults to WOB_DEFAULT_HEIGHT.
-o, --offset Define border offset in pixels, defaults to WOB_DEFAULT_BORDER_OFFSET.
-b, --border Define border size in pixels, defaults to WOB_DEFAULT_BORDER_SIZE.
-p, --padding Define bar padding in pixels, defaults to WOB_DEFAULT_BAR_PADDING.
-a, --anchor Define anchor point; one of 'top', 'left', 'right', 'bottom', 'center' (default).
May be specified multiple times.
-M, --margin Define anchor margin in pixels, defaults to WOB_DEFAULT_MARGIN.
-O, --output Define output to show bar on or '*' for all. If ommited, focused output is chosen.
May be specified multiple times.
--border-color <#argb> Define border color
--background-color <#argb> Define background color
--bar-color <#argb> Define bar color

I have also tested with FFFFFFFF and #FFFFFFFF same problem

Could you please check ?

Crash with SIGSYS due to illegal newfstatat system call

Starting with glibc 2.33, wob crashes due to a SIGSYS signal immediately after reading the first line of input:

Core was generated by `./wob'.
Program terminated with signal SIGSYS, Bad system call.
#0  0x00007f569a27a67e in fstatat64 () from /usr/lib/libc.so.6
(gdb) ba
#0  0x00007f569a27a67e in fstatat64 () from /usr/lib/libc.so.6
#1  0x00007f569a1ff763 in _IO_file_doallocate () from /usr/lib/libc.so.6
#2  0x00007f569a20e090 in _IO_doallocbuf () from /usr/lib/libc.so.6
#3  0x00007f569a20cfcc in __GI__IO_file_underflow () from /usr/lib/libc.so.6
#4  0x00007f569a20e146 in _IO_default_uflow () from /usr/lib/libc.so.6
#5  0x00007f569a20116c in _IO_getline_info () from /usr/lib/libc.so.6
#6  0x00007f569a2000ba in fgets () from /usr/lib/libc.so.6
#7  0x0000556e1203fccb in main (argc=1, argv=0x7ffdff3b0de8) at ../main.c:783

A small test program without Seccomp confirms that the newfstatat system call is now used by fgets

#include <stdio.h>

int main(void) {
    char s[100];
    return !fgets(s, sizeof(s), stdin);
}

giving rise to the following system call trace:

$ echo | strace ./a.out
execve("./a.out", ["./a.out"], 0x7ffd9d91ddd0 /* 74 vars */) = 0
brk(NULL)                               = 0x5587ce579000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffe34ad6210) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK)      = 0
openat(AT_FDCWD, "/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
close(3)                                = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=239432, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 239432, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9820752000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`|\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0 \0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0"..., 48, 848) = 48
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\253\363\262\251\201\\\f\326\344(\f\331\224t\323A"..., 68, 896) = 68
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2155984, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9820750000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 1884632, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f9820583000
mmap(0x7f98205a9000, 1359872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f98205a9000
mmap(0x7f98206f5000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x172000) = 0x7f98206f5000
mmap(0x7f9820741000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bd000) = 0x7f9820741000
mmap(0x7f9820747000, 33240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f9820747000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9820581000
arch_prctl(ARCH_SET_FS, 0x7f9820751580) = 0
mprotect(0x7f9820741000, 12288, PROT_READ) = 0
mprotect(0x5587cd3ea000, 4096, PROT_READ) = 0
mprotect(0x7f98207bc000, 8192, PROT_READ) = 0
munmap(0x7f9820752000, 239432)          = 0
newfstatat(0, "", {st_mode=S_IFIFO|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0
brk(NULL)                               = 0x5587ce579000
brk(0x5587ce59a000)                     = 0x5587ce59a000
read(0, "\n", 4096)                     = 1
exit_group(0)                           = ?
+++ exited with 0 +++

feature req: color segments

I'd like to be able to use different colors for different segments of the bar. Something like this:

One way to think of this would be as an extension to #67 where one would have to define something like --width 100 --overflow-width 150 if the expected overflow is 150.

Another (and preferred) way to think of this is splitting the bar to arbitrary number of segments with each one having a different color. The example image above, assuming the width of the bar is ~100, it would be something like

• for values in <0; 65> the color is white
• for values in (65; max> the color is red

Now I can only think of one practical use case: volume boost, which only needs two segments but I imagine other people might come up with something that can leverage more than two segments or even fancy things like gradients, etc.

Suggestion/question about colors

Hey it took me some times to figure out how to use colors and I am still not sure about the meaning of the first two hex value (#FF000000). Is this opacity ?

I think you should really provide some examples and documentation in the readme and manpage.

Create and maintain distribution packages

There is only one for Arch Linux. It would be nice to have packages for other popular distributions like Gentoo, Void and others.

Links to current packages are located in README.

Wob issues through multiple sway sessions

When executing sway from a TTY and exiting Sway more than once without logging out, wob doesn't work on sway sessions launched after the first one.

I had to add rm -f /tmp/wobpipe && ... to my swaynag/swaymsg exit keybind. That fixed the issue but there were still tail and wob processes, so I had to add pkill wob && pkill tail && ... to the command as well. So my exit keybind now looks like:

bindsym $mod+Shift+e exec --no-startup-id swaynag -t warning -m 'Do you really want to exit sway?' -b 'Yes, exit sway' 'rm -f /tmp/wobpipe && pkill wob && pkill tail && swaymsg exit'

I'm not sure if this is something you could fix programmatically within wob. I notice this issue as well with redshift so I have to add pkill redshift to the exit command as well.

Release signing key

Please link your release openpgp signing key somewhere visible.

It looks like key provided via github seems to match https://github.com/francma.gpg but its not linked anywhere.

seg fault

In brief: Trying wob 0.10.0 on my system just results in a seg fault.

Dist: Debian 11
Kernel: 5.8 (amd64)
DE: Gnome 3.36.4 (wayland of course)

repro:

• build wob, everything fine
• open terminal
• type 'wob'
• press return
• type integer between 0-100
• press return
  "Segmentation fault"

I'm not sure at this point what steps I could take to debug and give more information...

valgrind test fails for ppc64le

I am running the build and test as a part of the Ubuntu distribution for ppc64le.
This helps us simplify testing later when distributions are re-building and re-releasing.

During the build and test, I found that alpine, coding style check and static analyzer are passing. However valgrind test is failing with the error as

1/1 parse-input FAIL           0.42s (exit status 2)
Ok:                 0   
Expected Fail:      0   
Fail:               1   
Unexpected Pass:    0   
Skipped:            0   
Timeout:            0   
Full log written to /wob/build/meson-logs/testlog-valgrind.txt

Could you pl. take a look into the same.
Logs can be found at https://travis-ci.com/github/gururajrkatti/wob/jobs/457187995

Wob crashes if volume is highter than 100

If the volume is higher than 100, wob should keep showing 100% instead of crashing.

This can happen because unlike pulse/alsa, pipewire allows to increase volume without limit (even 10000%).

The -m argument doesn't help in this case.

.ini file configuration

With per output configuration it would be better to have configuration file instead of one long line of arguments.

https://github.com/benhoyt/inih

#49

#7

-c option doesn't work if wob.ini exists

I don't know if this is intended behaviour, but I'd assume not, so here I am.

I have two instances of wob running: one for brightness and the other for volume. I like to have brightness represented horizontally and volume vertically, so I've been using #97 for this purpose.

For this to work, I have to supply wob with two configuration files. Initially, I thought that I could have a "default" configuration file, which would be the one stored in ~/.config/wob/wob.ini, and would simply have to reference another configuration file with the -c option if I needed wob to use another set of configurations.

This, however, is not the case. If wob.ini exists, passing the -c option and referencing a file results in the following message:

usage: wob [-c config]

If it does not exist, I can simply reference configuration files individually for each wob instance, which is what I've been doing, having wob-brightness.ini and wob-volume.ini.

This is no big issue, of course, but it took some time to figure out what was wrong. If possible, it would be better for the error message to be more precise about wob's requirements or to change how passing the -c option works alltogether.

Segmentation fault since commit aec2abb94b0d038a13cb88418bd411a416f92230

After an update (after some time not updating) I noticed that my wob setup did not work anymore as expected. I'm on Arch Linux. I traced it down to a segmentation fault introduced in commit aec2abb (found it via git bisect).

For tests I ran wob like this

$ tail -f $XDG_RUNTIME_DIR/wob.sock | wob -vv
1631902749.243362 DEBUG log.c:111: Set log level to DEBUG
1631902749.243746 DEBUG pledge_seccomp.c:44: Adding syscall 228 to whitelist
1631902749.243763 DEBUG pledge_seccomp.c:44: Adding syscall 3 to whitelist
1631902749.243769 DEBUG pledge_seccomp.c:44: Adding syscall 60 to whitelist
1631902749.243776 DEBUG pledge_seccomp.c:44: Adding syscall 231 to whitelist
1631902749.243782 DEBUG pledge_seccomp.c:44: Adding syscall 72 to whitelist
1631902749.243794 DEBUG pledge_seccomp.c:44: Adding syscall 96 to whitelist
1631902749.243802 DEBUG pledge_seccomp.c:44: Adding syscall 7 to whitelist
1631902749.243809 DEBUG pledge_seccomp.c:44: Adding syscall 271 to whitelist
1631902749.243825 DEBUG pledge_seccomp.c:44: Adding syscall 0 to whitelist
1631902749.243830 DEBUG pledge_seccomp.c:44: Adding syscall 19 to whitelist
1631902749.243835 DEBUG pledge_seccomp.c:44: Adding syscall 47 to whitelist
1631902749.243840 DEBUG pledge_seccomp.c:44: Adding syscall 219 to whitelist
1631902749.243847 DEBUG pledge_seccomp.c:44: Adding syscall 46 to whitelist
1631902749.243855 DEBUG pledge_seccomp.c:44: Adding syscall 1 to whitelist
1631902749.243863 DEBUG pledge_seccomp.c:44: Adding syscall 20 to whitelist
1631902749.244417 DEBUG pledge_seccomp.c:57: Seccomp syscall whitelist successfully installed
1631902751.076187 INFO  main.c:898: [1]    125887 broken pipe                       tail -f $XDG_RUNTIME_DIR/wob.sock | 
       125888 segmentation fault (core dumped)  wob -vv

and the offending command was just

$ echo 10 >> $XDG_RUNTIME_DIR/wob.sock

The debug trace is as follows (but doesn't really help me track down the problem further):

(gdb) bt
#0  0x00007fde47698c0a in __strlen_sse2 () from /usr/lib/libc.so.6
#1  0x00007fde47666fd8 in __vfprintf_internal () from /usr/lib/libc.so.6
#2  0x00007fde476677a4 in buffered_vfprintf () from /usr/lib/libc.so.6
#3  0x00005626aa3ab3f3 in vfprintf (__ap=0x7ffcb1041fc0, __fmt=0x5626aa3ad540 "Received input { value = %ld, bg = %#x, border = %#x, bar = %#x, overflow = %s }", __stream=<optimized out>)
    at /usr/include/bits/stdio2.h:135
#4  _wob_log (importance=importance@entry=_WOB_LOG_INFO, file=file@entry=0x5626aa3ac055 "main.c", line=line@entry=898, 
    fmt=fmt@entry=0x5626aa3ad540 "Received input { value = %ld, bg = %#x, border = %#x, bar = %#x, overflow = %s }") at ../wob/log.c:89
#5  0x00005626aa3aa374 in main (argc=<optimized out>, argv=<optimized out>) at ../wob/main.c:891

If I can give you any more relevant details please ask. If you can give me further hints do debug it I'd be glad as well.

AUR install is broken

AUR install fails with:

:: Importing keys with gpg......
gpg: keyserver receive failed: No data
==> Error: Problem importing keys

Fix from: https://aur.archlinux.org/packages/wob/

gpg --keyserver keys.openpgp.org --receive-keys 5C6DA024DDE27178073EA103F4B432D5D67990E3

Not sure what causes the gpg import to fail, but it does.

Exec doesn't run custom configuration

Hi, I have the following lines in my sway config file:

set $WOBSOCK $XDG_RUNTIME_DIR/wob.sock
exec mkfifo $WOBSOCK && tail -f $WOBSOCK | wob -a bottom -H 20 -W 1920 -o 0 -b 0 -p 0 -t 1500 --overflow-mode nowrap

After reboot or start up, configuration seems to be the default one.
When getting process information I get:

$ ps xa | grep wob
    923 ?        Ss     0:00 /usr/bin/wob

Fails to build on openSUSE Tumbleweed

When trying to build wob on openSUSE Tumbleweed, the following error appears after running ninja -C build-release:

$> ninja -C build-release
ninja: Entering directory `build-release'
[1/6] Compiling C object 'xdg_shell_lib@sta/meson-generated_.._xdg-shell-client-protocol.c.o'.
FAILED: xdg_shell_lib@sta/meson-generated_.._xdg-shell-client-protocol.c.o 
cc -Ixdg_shell_lib@sta -I. -I.. -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 '-DWOB_VERSION="0.2"' -fPIC -MD -MQ 'xdg_shell_lib@sta/meson-generated_.._xdg-shell-client-protocol.c.o' -MF 'xdg_shell_lib@sta/meson-generated_.._xdg-shell-client-protocol.c.o.d' -o 'xdg_shell_lib@sta/meson-generated_.._xdg-shell-client-protocol.c.o' -c xdg-shell-client-protocol.c
xdg-shell-client-protocol.c:33:10: fatal error: wayland-util.h: No such file or directory
   33 | #include "wayland-util.h"
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
[2/6] Compiling C object 'wlr_layer_shell_unstable_v1_lib@sta/meson-generated_.._wlr-layer-shell-unstable-v1.c.o'.
FAILED: wlr_layer_shell_unstable_v1_lib@sta/meson-generated_.._wlr-layer-shell-unstable-v1.c.o 
cc -Iwlr_layer_shell_unstable_v1_lib@sta -I. -I.. -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 '-DWOB_VERSION="0.2"' -fPIC -MD -MQ 'wlr_layer_shell_unstable_v1_lib@sta/meson-generated_.._wlr-layer-shell-unstable-v1.c.o' -MF 'wlr_layer_shell_unstable_v1_lib@sta/meson-generated_.._wlr-layer-shell-unstable-v1.c.o.d' -o 'wlr_layer_shell_unstable_v1_lib@sta/meson-generated_.._wlr-layer-shell-unstable-v1.c.o' -c wlr-layer-shell-unstable-v1.c
wlr-layer-shell-unstable-v1.c:30:10: fatal error: wayland-util.h: No such file or directory
   30 | #include "wayland-util.h"
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

All the previous steps run fine:

$> meson build-release  --buildtype release          
The Meson build system
Version: 0.51.2
Source dir: /home/mrey/repos/mrey/github/wob
Build dir: /home/mrey/repos/mrey/github/wob/build-release
Build type: native build
Project name: wob
Project version: 0.2
C compiler for the host machine: cc (gcc 9.2.1 "cc (SUSE Linux) 9.2.1 20190903 [gcc-9-branch revision 275330]")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.6.3)
Run-time dependency wayland-protocols found: YES 1.18
Program wayland-scanner found: YES (/usr/bin/wayland-scanner)
Run-time dependency wayland-client found: YES 1.17.0
Library rt found: YES
Build targets in project: 8
Found ninja-1.9.0 at /usr/bin/ninja

wob crashes when an empty string is echoed to fifo

Seeing this on wob and wob-git on Arch Linux.

styling with colors

Is there a way to style wob with colors, radius or else ?

change color format

I believe the color format should be <RRGGBB[AA]> instead of the current <#AARRGGBB>. The same as in swaynag for example

Replace -v with WOB_LOG_LEVEL env variable

List of log levels:

crit, err, warning, notice, info, debug

And add example on how to turn logging on if wob is started as a systemd service:

systemctl --user edit wob.service

[Service]
Environment=WOB_LOG_LEVEL=debug

WOB Not working after logout (swaywm)

WOB isn't work after i logout the sway,

Bad system call (core dumped) on aarch64 (manjaro)

I experienced this crash with the latest release-- I installed from AUR first, and then tried to just check out the latest from this repo (and built using the instructions in the readme). I get the same result either way.

If it's helpful, this is Manjaro ARM 20.08, on a pinebook pro.

Since it's syscall related, I thought perhaps the output of strace might be helpful:

execve("/usr/local/bin/wob", ["wob"], 0xffffe4530d50 /* 32 vars */) = 0
brk(NULL)                               = 0xaaaaf4821000
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=188644, ...}) = 0
mmap(NULL, 188644, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffff9904b000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libwayland-client.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0`S\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=68200, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffff990a6000
mmap(NULL, 131856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffff9902a000
mprotect(0xffff99039000, 61440, PROT_NONE) = 0
mmap(0xffff99048000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0xffff99048000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\200\"\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=31016, ...}) = 0
mmap(NULL, 94560, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffff99012000
mprotect(0xffff99019000, 61440, PROT_NONE) = 0
mmap(0xffff99028000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0xffff99028000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libseccomp.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\200Q\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=313224, ...}) = 0
mmap(NULL, 376880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffff98fb5000
mprotect(0xffff98fe8000, 65536, PROT_NONE) = 0
mmap(0xffff98ff8000, 106496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x33000) = 0xffff98ff8000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\350>\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1795200, ...}) = 0
mmap(NULL, 1493624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffff98e48000
mprotect(0xffff98f9c000, 65536, PROT_NONE) = 0
mmap(0xffff98fac000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x154000) = 0xffff98fac000
mmap(0xffff98fb2000, 10872, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffff98fb2000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libffi.so.7", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\260\31\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=34800, ...}) = 0
mmap(NULL, 99528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffff98e2f000
mprotect(0xffff98e37000, 61440, PROT_NONE) = 0
mmap(0xffff98e46000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0xffff98e46000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0pp\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=162912, ...}) = 0
mmap(NULL, 192840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffff98dff000
mprotect(0xffff98e19000, 65536, PROT_NONE) = 0
mmap(0xffff98e29000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0xffff98e29000
mmap(0xffff98e2b000, 12616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffff98e2b000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffff990a4000
mprotect(0xffff98fac000, 12288, PROT_READ) = 0
mprotect(0xffff98e29000, 4096, PROT_READ) = 0
mprotect(0xffff98e46000, 4096, PROT_READ) = 0
mprotect(0xffff98ff8000, 102400, PROT_READ) = 0
mprotect(0xffff99028000, 4096, PROT_READ) = 0
mprotect(0xffff99048000, 8192, PROT_READ) = 0
mprotect(0xaaaace4b2000, 4096, PROT_READ) = 0
mprotect(0xffff990aa000, 4096, PROT_READ) = 0
munmap(0xffff9904b000, 188644)          = 0
set_tid_address(0xffff990a4c60)         = 19635
set_robust_list(0xffff990a4c70, 24)     = 0
rt_sigaction(SIGRTMIN, {sa_handler=0xffff98e05af8, sa_mask=[], sa_flags=SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0xffff98e05bb8, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
ioctl(2, TCGETS, 0xffffd306a5b0)        = -1 ENOTTY (Inappropriate ioctl for device)
statfs("/dev/shm/", {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=485999, f_bfree=463632, f_bavail=463632, f_files=485999, f_ffree=485927, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV}) = 0
futex(0xffff98e2e0a0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/dev/shm/wob-0", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 3
unlinkat(AT_FDCWD, "/dev/shm/wob-0", 0) = 0
ftruncate(3, 80000)                     = 0
mmap(NULL, 80000, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xffff99066000
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/run/user/1001/wayland-0"}, 27) = 0
brk(NULL)                               = 0xaaaaf4821000
brk(0xaaaaf4842000)                     = 0xaaaaf4842000
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\0\0\1\0\f\0\2\0\0\0\1\0\0\0\0\0\f\0\3\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 24
ppoll([{fd=4, events=POLLIN}], 1, NULL, NULL, 0) = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\2\0\0\0\0\0\34\0\1\0\0\0\7\0\0\0wl_shm\0\0\1\0\0\0\2\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 1664
fcntl(3, F_DUPFD_CLOEXEC, 0)            = 5
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)  = 0
seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument)
seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=20, filter=0xaaaaf482ae50}) = 0
ppoll([{fd=4, events=POLLIN}, {fd=0, events=POLLIN}], 2, NULL, NULL, 0 <unfinished ...>) = ?
+++ killed by SIGSYS (core dumped) +++

Add configuration options

Add command line configuration options, similar to xob. It would be great to have at least the maximum and timeout options. Style configuration would also be nice to have, but does not seem as critical.

Does this seem like something you would like to add? If so I'd be happy to submit a PR.

Use pixman for drawing

Feature request: Allow specifying width and height in % of screen

I would like to have wob with height 5px and width 90% of the screen. If I make it X pixels wide, it will not be sized correctly on my second screen which has lower resolution. How hard would it be to implement this?

Make alpha channel in color optional

Originally posted by @532910 in #70 (comment)

Feature request: Add option to display the actual percentage number in the bar

Sometimes when changing the volume or brightness when in fullscreen, it might be usefull to display the percentage number in the bar as your will not be able to see your top/bottom panel. This is especially useful when incrementing or decrementing by 1 percent at the time.

I have the following in mind:

Option

--show-number

Shows the percentage number in the bar.

Config

--text-position <middle> <top> <bottom> <right> <left>

The position of the number in the bar. Left, right, top and bottom shows the number outside of the border in the center of their position. Middle displays the number within the bar, in the middle.

--text-color <rrggbb[aa]>

Text color in rrggbb or rrggbbaa.

--font <font>

Sets the font of the text.

--font-size

Fixed font size for the number text. (should not exceed the size of the bar)

--text-margin-right

Set margin on the left side of the text.

--text-margin-left

Set margin on the right side of the text.

--text-margin-top

Set margin above the text.

--text-margin-bottom

Set margin below the text.

Margins should not cause the text to exceed the border of the bar, if a value greater than the possible value is passed, the last possible value is used.

Improve documentation

I'm not used to write longer technical texts in English so anything helps. More examples (with colors and styling) in README would be nice and overall better wording of things.

Wob on focussed screen.

Is it possible to make Wob appear on the output with the current focus.
I don't mind implementing this myself if someone has some pointers of where to start..

OpenGL rendering

icons and text support feature request

Alternative amixer script using sed

amixer sset Master toggle | sed -E -n '/\[on\]/ s/.*\[([0-9]+)%\].*/\1/ p; /\[off\]/ s/.*/0/ p' > $SWAYSOCK.wob
amixer sset Master 5%- | sed -E -n 's/.*\[([0-9]+)%\].*/\1/ p' > $SWAYSOCK.wob
amixer sset Master 5%+ | sed -E -n 's/.*\[([0-9]+)%\].*/\1/ p' > $SWAYSOCK.wob

Feature request: Allow values over 100

It would be nice if values over 100 would be accepted and just displayed as if it they were 100. That way, when using wob for volume with audio boost (which allows values over 100), no hacky workaround would be needed to dsplay it correctly.

Remove meson, replace with Make or cmake

meson pulls in a huge dependency tree into the build environment, but this is only a small C codebase... something like Makefile or a cmake based build would fit way better.

Feature request: use environment variables for colors

We're using this on sxmo for volume and brightness. It would be nice to be able to let the user theme wob with environment variables, for example WOB_BORDER, WOB_BACKGROUND, WOB_COLOR...

Feature request: Rounded corners

It would be cool to have rounded corners:
--rounded-corner <px>

A value of 0 would keep straight lines in the corners (both edges).
A value greater than 0 would 'pull' the middle point forming an arc.

Should wob really exit due to invalid input?

I don't have a strong opinion on this but I was wondering if it wouldn't be better to just ignore invalid input (and print a warning to stderr or show some graphical indication of a failure, e.g. a red overlay bar or error message).

An advantage of the current behaviour (exiting) is that errors in scripts etc. become more apparent, but it might also be annoying when testing scripts as one would possibly need to restart wob quite often. Or if users aren't aware of this behaviour and don't see the output (e.g. when started via sway's exec) they might think that it did crash for another reason.

If there where some graphical indication that invalid input was received this might be better / more comfortable. Or one could introduce a flag to let the user choose the behaviour.

Next release

I'd like to build and bundle a current version of this application since we rely on some more recent changes. Would you be open to releasing the next version? Since there are some breaking changes, it perhaps would be worth making it a major version step?

Allow multiple wobs to be run together

If it was possible to have multiple wob bars and have each one appear differently this application would be a lot more useful.

The use case I am thinking of is when you change brightness it is a sun icon with the overlay and similarly, when you change the volume it is a speaker icon.

I know this probably ties into #7 but it is slightly different.

Happy to work on this myself if someone had any ideas about how it could be done.

Change color format from #argb to #rgba

Most RGB with alpha color representations are in #RRGGBBAA format - for example

• https://codeberg.org/dnkl/foot/
• swaybg