2020.10.3

• Breaking change: refactor i3pyblocks.blocks.base.ExecutorBlock. Now it is called i3pyblocks.blocks.base.SyncBlock, and it haves a much better API to create blocks that depend on non-async libraries. It has two new methods, click_handler_sync and signal_handler_sync, that are normal functions and works as expected (running inside a executor so they don't block the main asyncio loop). Also, the main method in SyncBlock was renamed from run to start_sync, making SyncBlock API an effective counterpart of i3pyblocks.blocks.base.Block
• Refactored i3pyblocks.blocks.pulse.PulseAudioBlock to use the new API from SyncBlock. This should fix some issues with freeze when clicking on it. Also it finally implements signal_handler_sync, so this block is updated when a signal is send to it
• Add i3pyblocks.blocks.base.PollingSyncBlock. This is the synchronous counterpart of i3pyblocks.blocks.base.PollingBlock, and while it may seem unnecessary (we can use PollingBlock even on non-asyncio libraries like shown in i3pyblocks.blocks.ps blocks, for example), it have a good use case: when a library has functions that are (possible) slow, using PollingBlock would freeze the i3pyblocks, while with PollingSyncBlock i3pyblocks will continue to work even if the function call never returns. One example of this is in i3pyblocks.blocks.x11.CaffeineBlock, since X11 calls can takes multiple seconds to run over a network or when X server is busy. This block used to call its blocking functions inside a executor, but it is implemented much more easily with the new PollingSyncBlock
• Like said above, refactored i3pyblocks.blocks.x11.CaffeineBlock to use the new PollingSyncBlock. This fixed some issues in this block
• Add sensor_regex and sensor_index params to i3pyblocks.blocks.ps.SensorsTemperatureBlock