Add two new parameters: theme and iconset
Add a placeholder class core.theme.Theme, an instance of which is passed
in to the i3 output object (which is the only object that should ever
have need of the theme, hopefully).
To make it easier to update individual modules, separate the call to
update() and the call to actually drawing the status.
Additionally, this avoids the "side effect" of updating when drawing the
status line.
To the main application, add an input thread that "simply" reads
sys.stdin events and transmits them via core.input.
Additionally, set up some initial logging (yeah, for threading, this is
needed immediately)
The core.output module now manages the list of modules and retrieves the
widgets inside draw() itself. That way, details of drawing/updating
widgets are not visible from the outside anymore.
Add generic "draw()" method that redirects internally to the actual
calls. These can now produce JSON, which is nicer because:
1. Easier to use during testing
2. More flexible
3. Centralizes printing (somewhat)
Still, the "suffix" concept isn't really nice, but so far, I have no
better approach.
Add logic for parsing commandline options, and a preliminary stub for
loading modules.
Note: The idea is that core.module.load() will return a valid, but
empty, module that displays an error, if the module cannot be loaded
Experimental re-implementation of core functionality with the aim:
- Depend only on the Python Standard Library for core
- If modules are missing elsewhere, *never* throw
- Unit test *everything*
- Cleaner and more minimal implementation
- Better integration points for existing implementations (charts,
braille, etc.)
- Full backwards-compatibility with existing module system (except where
modules can be vastly simplified)
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
