Allow a widget to set "theme.exclude" to extend any part of a theme
(e.g. the suffix). Note that this can later, on demand, be extended to
allow a list of elements to be passed in.
see #401
If the theme name provided by the user is a file, load the theme from
there.
Note: This change automatically enables a theme to load iconsets from a
file name, instead of using a iconset name.
fixes#319
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
When loading a color scheme (e.g. wal) fails for some reason, do not
abort bumblebee-status. Instead, log an error message and continue
without the colors.
fixes#263
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
In order to use symbol files, symbol.json needs to be created manually
now.
Also, remove symbol usage from the prepackaged themes to avoid
breakage.
fixes#216
Theme writers are now able to use FontAwesome names and IDs instead of
the symbols itself!
The implementation itself is *slightly* hacky and might get improved in
the future: Upon the first start, a YAML file containing the FontAwesome
symbols is fetched from
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/src/icons.yml
Note: This is only done once - to retrigger this (i.e. for an update),
please just delete the file and restart bumblebee-status.
Then, in the *icon* theme itself, you can use ${<name or id>} instead of
the actual symbol.
Names and IDs can be found here:
http://fontawesome.io/cheatsheet/
(simply remove the "fa-" prefix)
An example is provided in themes/icons/awesome-fonts.json.
(finally) fixes#20
sorry for taking so long :)
List themes only once, even if they are present multiple times in
different locations.
(Yes, I know that list(set(result)) would do the same, but here, I'd
like to not waste memory and be a bit faster).
see #203
In a theme file, it is now possible to provide an array of "color
definitions", which allow you to use names instead of colors throughout
the theme file.
Currently, only the colorset "wal" is supported, which reads all colors
from the wal JSON file (~/.cache/wal/colors.json) and makes them usable
in the theme (as "foreground", "background", "cursor", "color12", etc.).
An example of this can be found in the theme wal-powerline.
see #185
In order to do that, change the theme engine so that a theme can
override settings in the iconsets. Was probably a bug to begin with that
this was not possible.
For modules that use aliases, until now, *only* the alias theme was
considered. This is typically a bad idea (tm), as the "generic" case is
that of a module theme (e.g. "disk", not that of a theme per instance of
the module (i.e. "home", "root", etc.)).
Therefore, introduce the concept of a "class" theme that can be
optionall overridden by a specific module theme.
As a pleasant side-effect, this should bring back the disk icons for all
instances of the disk module :)
fixes#79
If a module defines a callback for a widget's text, an optional
decorator "@bumblebee.output.scrollable" can be used to make the text
scrollable.
In those cases, the desired width is set to (in decreasing order of
priority):
1. whatever the widget defines as "theme.width"
2. whatever the theme defines as "width" for the module
3. whatever the commandline parameter "width" for the module is set to
4. 30 (determined by unfair dice roll)
see #27
Added theme-options ("minwidth" and "align") for setting the minimum
width and the alignment of a widget.
Also, allow widget to provide defaults for the theme options by setting
an attribute in their store called "theme-<name of the theme option>".
For example, a widget can now define a default alignment by using:
widget.set("theme-align", "default-value").
If the computer runs on AC, display that instead of showing "100%" in
the status.
Also, if reading the charging status fails for some reason (except the
computer being on AC), go into critical state and display "n/a".
see #23
Re-add the NIC module with all its functionality (hopefully...).
This introduces a new concept: Instead of having separate queries for
critical and warning (which really are just another set of states), a
module can now return a list of states for each widget. All the state
information is then merged together into a single theme. So, for
instance, the NIC module can return a state saying "critical -
wlan-down", which applies the theme information for both "critical" and
"wlan-down".
see #23
Each widget can now return a state using the method "state()". This
string is then used to look up a theme information which is used instead
of the default or module theme, if found.
see #23
Add customized separators:
* The default separators are automatically disabled if custom separators
are used (to "just" disable the default, use empty custom separators)
* Use previous background color as their background color and the
current background color as foreground color
* Allow the separator-block-width to be configured
see #23
Allow a theme to define a "cycle" of attributes that are cycled through
on a widget-per-widget basis (e.g. for alternating the widget
background). These cycles take precedence over the default values, but
can be overridden by module-specific theme instructions.
see #23
Allow module-specific theme information to overload "default"
configuration. I.e. it is now possible to have specific prefix or
postfix configurations for different modules. The module name is derived
for each widget from the module (__module__) from which it was
instantiated.
see #23
Allow sub-themes ("iconsets") to be merged into the "main" theme. That
way, effectively, it's possible to define colors and icons in separate
JSON files.
see #23
Until now, widgets were re-created during each iteration. For multiple,
reasons, using static widget objects is much easier, so instead of
creating new widgets continuously, modules now create the widgets during
instantiation and get the list of widgets passed as parameter whenever
an update occurs. During the update, they can still manipulate the
widget list by removing and adding elements as needed.
Advantages:
* Less memory fragmentation (fewer (de)allocations)
* Easier event management (widgets now have static IDs)
* Easier module code (widget contents can simply be the result of a
callback)
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
