Regular i3bar events *can* contain the character [, so a better
mechanism for detecting the initial opening [ is required. For now, do a
minimal change that requires the line to *start* with [. This should
never be the case for i3bar events, which are always JSON objects.
fixes#318
If a callback command cannot be executed, do not terminate the whole
bar. Furthermore, if such a failure occurs, try to fall back to a
globally (i.e. non widget-specific) command, so that callbacks
registered in the engine itself (such as mouse-wheel scrolling) still
function properly.
fixes#166
Somehow, the fix in the previous commit didn't work, it seems that
sometimes epoll() doesn't trigger, even if there is more data in
sys.stdin. I'm sure I'm doing something horribly wrong here.
Anyhow, as a quick fix, check for the open bracket to be sure to not
buffer the first event too long.
Re-enable the possibility to define custom mouse actions by binding
commands to "<alias|module>.<left-click|right-click|...>". These
commands are then executed as shell commands.
fixes#30
Until now, as soon as a widget registered *any* callback, the default
callbacks (e.g. scroll up/down to go to next/previous workspace) didn't
work anymore, as there was a better match for the general registration
(even though not for the button).
To fix this, merge the callback registration into a flat registration,
where a key is calculated from the ID of the registrar and the
registered button.
see #23
Make input thread non-blocking by using select(). This increases the CPU
utilization a bit (depending on the timeout), but makes the thread exit
cleanly, even if an exception is thrown in the main thread.
see #23
Create infrastructure for input event handling and add i3bar event
processing. For each event, callbacks can be registered in the input
module.
Modules and widgets both identify themselves using a unique ID (the
module name for modules, a generated UUID for the widgets). This ID is
then used for registering the callbacks. This is possible since both
widgets and modules are statically allocated & do not change their IDs.
Callback actions can be either callable Python objects (in which case
the event is passed as parameter), or strings, in which case the string
is interpreted as a shell command.
see #23
