Commit graph

10 commits

Author SHA1 Message Date
Tobi-wan Kenobi
70f138b97b [tests/i3bar-input] Add input tests for i3bar protocol
Also, replaced the MockModule with a generic mock object.
2017-03-05 08:35:15 +01:00
Tobi-wan Kenobi
cdbddcfff7 [tests/i3bar-input] Add tests for i3bar input processing 2017-03-05 07:56:10 +01:00
Tobi-wan Kenobi
6dbe440cb5 [tests] Purge tests and start with a clean implementation of subprocess
Seems like subprocess and friends (Popen, communicate) are not so easy
to mock cleanly. Therefore, start from scratch and carefully write test
by test, until (at least) the old test coverage has been restored.
2017-03-04 11:25:52 +01:00
Tobi-wan Kenobi
f6be25bc73 [core/input] Move from select to epoll
Use epoll instead of select in order to be able to use level-triggered
semantics and not get stuck on the first event.
2016-12-17 07:43:38 +01:00
Tobi-wan Kenobi
75f5af4866 [core/input] Skip partial events
Clicking on a separator creates partial events ("instance" missing).
Ignore those events, as they crash the input processor.

fixes #31
2016-12-11 13:43:34 +01:00
Tobi-wan Kenobi
4bd13c2f63 [tests] Refactor i3barinput
Use the assertMouseEvent helper in i3barinput.

see #23
2016-12-11 08:01:16 +01:00
Tobi-wan Kenobi
029492e16d [core] Non-blocking input thread for i3bar events
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
2016-12-10 13:45:54 +01:00
Tobi-wan Kenobi
918d7a6046 [core/input] Add callback deregistration
Enable components to unregister callbacks (i.e. for dynamic widgets).

see #23
2016-12-10 10:26:07 +01:00
Tobi-wan Kenobi
9ce7739efb [tests] Add specific tests for CPU module
* Check that the left mouse button action works
* Check that the format is OK

see #23
2016-12-09 22:28:04 +01:00
Tobi-wan Kenobi
e72c25b0bc [core] Add input processing
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
2016-12-09 19:29:16 +01:00