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 :)
The moon icon seems to make more sense for night time.
Add a datetime icon so you get a clock when using datetime.
Change the CPU icon to the microchip character.
The current thermometer icon isn't actually included in fontawesome, requiring a user to install and find another font that does support it, such as symbola or nota-emoji
Since this is for font-awesome it would make sense to only require font-awesome.
Set the minimum width for uplink and downlink widgets to "down 1000MB",
which should be plenty, and change alignment to right (personally, I
find this looks nicer).
To not have the icons on the left side "jump around" depending on the
value, make them suffixes.
If this solution is not sufficient, alternatively, the widget itself
could perform value padding. In that case, the whole alignment and
min-width settings would be obsolete and the icons could remain on the
left side.
* use psutil instead of "ifconfig" in order to avoid external command
calls
* fix a small bug in the ascii theme (missing colon)
* show statistics per-nic
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
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
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
Add code that allows themes to be merged (i.e. if certain elements are
not present in a theme, another theme can be "overlaid" to add missing
elements).
Effectively, this is used to create the logical concept of an "icon
theme", which is loaded after the main theme. So, the main theme can
define colors, and the icon theme fills in any missing elements
(practically, all the icons in the form of prefixes and suffixes).
Icon sets are defined in a theme using the "icons" directive, which
should be an array.
see #17
