[WIP] Execute custom user commands or scripts on a variety of rofi events

[giomatfois62]

This pull request addresses issue #2032, making it possible to execute custom user commands or scripts on a variety of rofi events. The following events are covered for now:

• Selected entry change (forward current entry name to user command)
• Entry accepted (forward accepted entry name to user command)
• Menu canceled
• Mode changed
• Menu error (forward error text to user command)
• Screenshot taken (forward screenshot path to user command, seemed cool to play a camera shutter sound in this case)

Custom commands can be specified from command line as follows:

rofi -on-selection-changed "$HOME/play_select.sh {entry}" \
     -on-entry-accepted "$HOME/play_accept.sh {entry}" \
     -on-menu-canceled "$HOME/play_exit.sh" \
     -on-mode-changed "$HOME/play_change.sh" \
     -on-menu-error "$HOME/play_error.sh {error}" \
     -on-screenshot-taken "$HOME/play_camera.sh {path}" ...

Here's an example bash script to react to "selected entry change" playing a sound:

#!/bin/bash

coproc aplay -q /home/mat/Music/selecting_an_item.wav

Arguments to user commands enclosed in curly braces will be replaced with corresponding values (e.g. {entry} with currently selected or accepted entry, {error} with error text etc.). Among other things, this allows the use of a synthetic speaker (like espeak or piper) to read aloud rofi interactions. Here's an example bash script to read aloud currently selected entries using espeak:

#!/bin/bash

killall espeak
echo "selected: $@" | sed -e 's///g' | espeak

The use of "coproc" for playing sounds with aplay is suggested, as the first example script shows, otherwise the rofi process will wait for sounds to end playback before exiting, and that can be annoying if someone concatenate multiple rofi menus (cough cough..).

Some things I don't like with current implementation:

• "selected entry change" user command is called inside selection_changed_callback. This function is strangely called multiple times for the same entry if icons are enabled (I guess once when the entry is selected and once when the icon is displayed but sometimes i see it called 3-4 times), thus I had to make a dirty hack to store the current index and compare it with the one passed to the function every time. I would like to find a cleaner approach, perhaps it's better to compare the current entry text instead of the current entry index.
• There seems to be no way to get the list of available modes from RofiViewState, unless the sidebar is enabled (then i can get the mode names from the textboxes stored in the state). The mode change logic seems to be implemented in rofi.c and the view only signals it setting MENU_NEXT|MENU_PREVIOUS and the like in the return value. It would be nice to forward the mode name to the command that reacts to menu mode changed (e.g. "$HOME/play_change.sh {mode}").

For the callback names (on-selection-changed etc.) I tried to be descriptive enough without making them too long, but I'm certainly open to different suggestions, as well as for other rofi events worth provisioning with custom commands.
My first experiments were made using an actual C audio library integrated in rofi, but this implementation coupled with simple bash scripts does the job as well and is much more flexible.

Let me know what you think.

[its-19818942118]

this looks very neat. and simple to use too. exactly what i was going for. a settings option for adding sounds. i wanted to suggest espeak but wasnt sure if it was possible to implement read aloud options. thanks @giomatfois62