make sure that for a given event (widget/object/module, whatever), only
a *single* input event per button can be registered at one time.
the problem otherwise is with modules that re-register their widgets
with the same IDs (cmus, spotify, etc.): Each time the widget is
re-created (each intervall, typically), it re-registers an input event,
creating an always longer list of callbacks being executed when the
button is clicked (not speaking of the memory leak this introduces).
fixes#668
make it possible to toggle the display state of a widget between
"displayed" and "minimized" also for modules that re-create their
widgets during each iteration.
see #661
by default, allow toggling the minimized state of a widget via the
middle mouse and draw a single unicode char instead of the actual
widget, maintaining all states.
fixes#661
Previous code accepted the "first" hit in a theme - particularly, if a
module is called "A" and a *different* module "B" uses "A" as state, a
widget of module B with state A would be themed as *module* A, wrongly.
Essentially, made sure that the last (most specific) themeing "wins".
fixes#647
when scrolling text that is subject to *slight* changes (e.g. a song
that contains the current position within the song), allow for slight
variations in the displayed text.
fixes#629
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...
to make errors easier to diagnose, do not scroll them, but instead fully
show them.
also, re-introduce the supplementary fields for the dwm bridge, kudos to
@somospocos
first, this fixes#607
also, i think it slightly simplifies code to make "simple" stuff like
names, etc. attributes instead of methods all the time.
so, expect this to be extended to other components, as well.
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.
According to the unit tests, at least, the old functionality is back
again - with the additional i3 block abstraction in output in place.
Also, pango support is temporarily removed again and will be
re-implemented based on the new architecture.
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).
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.
Add a (half-finished) input library, that for now simply allows
registration and triggering of events.
As next steps, the trigger will happen as part of a separate thread that
reads input events.
Additionally, invoking commands via a execute() will be supported.
Thirdly, there is need of a way to selectively update the affected
modules (widgets), which should be possible given that the event
contains both the instance (widget ID) and name (module name).
Parse '-p' parameters and make them accessible via 'parameter()' from
within a module (basically, restore the previous configuration
facility).
Still TODO: Add support for configuration files.
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.
To maintain backwards compatibility (and because I think it's an OK
design choice), keep the widget concept (a single module can produce
multiple widgets).
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
