When pressing the middle mouse button (and it's not assigned to any
other functionality), the module (i.e. all widgets of that module) will
disappear and be replaced with the module's icon (or prefix, as
fallback) and an ellipsis.
fixes#264
Add an option to load a user-specified icon theme (which will override
the theme's icons).
Also, commit a first version of a set of icons from the ionicons set
(see http://ionicons.com/).
see #252
Do not print any debugging messages unless "-d" has been specified on
the commandline.
Also, introduce two "special" logfiles "stdout" and "stderr" to log to
stdout and stderr, respectively.
fixes#213
Override sys.stdout and sys.stderr in an attempt to enforce utf-8
encoding. Probably this will cause all kinds of weird issues down the
line, but at least, it seems to solve the immediate issue.
fixes#176
* Unless debugging has been enabled, log to stderr (i.e. do *not* try to
open a file)
* When debugging into a file, choose a location that is likely to be
writeable by the user (i.e. the user's home directory)
* Location of the logfile can also be specified
fixes#62
* If an exception is thrown, catch it and show a (somewhat) nice error
message in the i3bar instead of the normal content
* Add a flag "-d" for debugging into a debug log. Currently, this only
logs commandline calls as they occur and their return values, as well
as exceptions.
fixes#58
The cpu module now has cpu.warning and cpu.critical thresholds. If the
CPU utilization is higher than any of those values, the widget's state
changes to warning or critical, respectively.
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
Add custom exceptions and add error handling to the engine's module
loading logic. I.e. when a non-existent module is loaded, an exception
is thrown now.
see #23
This is going to be a bit more comprehensive than anticipated. In order
to cleanly refactor the core and the engine, basically start from
scratch with the implementation.
Goals:
* Test coverage
* Maintain backwards compatibility with module interface as much as
possible (but still make modules easier to code)
* Simplicity
see #23
