OK - so I have to admit I *hate* the fact that PIP seems to require a
subdirectory named like the library.
But since the PIP package is something really nifty to have (thanks to
@tony again!!!), I updated the codebase to hopefully conform with what
PIP expects. Testruns so far look promising...
Until now, using a list as prefix/suffix didn't work as expected,
because the corresponding method for retrieving the value was called
multiple times, and each time, the next icon would be retrieved.
Changed the logic inside the theme to only update the indices every time
that an actual update was happening.
With this commit, it is possible to add pango directives inside every
piece that supports direct output (e.g. defaults/prefix or <module
name>/prefix) and those will be merged - i.e. it is possible to specify
defaults inside "defaults" and override/specify in the particular
modules.
The idea is to simplify the way the output module currently works by:
- introducing an abstraction that represents blocks; these abstractions
contain all data - uninterpreted - required to draw a block
- separately from that, whenever the block is serialized into JSON,
do the interpretation (pango vs. non-pango, etc.)
This - theoretically - should simplify code by creating two separate
concerns: collecting the data and actually interpreting it.
Allow any piece of a theme that specifies a set of attributes (default,
cycles, states, widgets) to use pango *instead* of the usual attributes.
If pango is present, this will have precedence.
A practical example of this can be found in the powerline-pango theme,
which is added solely for demonstration purposes.
fixes#531
When rotating theme values (e.g. the "charge" icon of the battery
module(s)), until now, the code just showed the raw list (because it
wasn't aware of the need to rotate).
Implement a generic "load keywords and replace during runtime"
mechanism, with the first concrete use-case of WAL colors (load them
during startup, and during runtime, whenever a matching name is found in
the keywords, replace with the actual color)
Add states to the modules and widgets. Widgets are mostly just a
pass-through (backwards compatibility, and ease of use - making states
directly inside the widgets would require more code inside the modules
to ensure that each widget is correctly updated).
Still missing:
- Separators during partial update (right now, it takes one interval
until separators are drawn correctly)
Add a way for themes to specify custom separators. Doing that, make
nicer interfaces for drawing "supplementary" components (separators)
for widgets and generalize the attribute retrieval within the theme.
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).
