There was a typo and it said `ni` rather than `nil`. Luckily (or unluckily, it
depends on how you see it), the variable `ni` isn't defined anywhere so it
default to... `nil`.
Not worth making another release with this change only as nothing actually
breaks, so it will end up in the next release.
Rather than setting a path to the icons, use lgi to get the current GTK theme
and then look up the icons. Then set the image as a cairo surface by using the
GTK api directly.
With this change, one can modify their GTK icon theme (e.g. with lxappearance),
restart AwesomeWM and have the widget's icon automatically updated.
DisplayDevice is a "special" device object that represent what a widget should
display, however it does *not* give information about Line Power. E.g. when a
laptop has no battery but is plugged on the mains, DisplayDevice says that no
device should be displayed and the icon is set to "battery-missing" (which is
in fact true).
However, if we are working, it means that we must be getting power from
somewhere, so let's display something in the tooltip anyway.
Command line example
$ upower -i /org/freedesktop/UPower/devices/DisplayDevice
power supply: no
updated: Sun 05 Nov 2017 04:19:48 PM GMT (415 seconds ago)
has history: no
has statistics: no
unknown
warning-level: none
icon-name: 'battery-missing-symbolic'
See also https://upower.freedesktop.org/docs/UPower.html#UPower.GetDisplayDevice
Instead of using Awesome's DBus api, use directly the on_properties_changed
method on the device object. This change removes a lot of boilerplate code and
makes the module much simpler!
- remove section about installing from source: this requires some juggling and
symlinking, so I will leave it to people who *really* want to do it
- explain how to export the local luarocks path when installint locally with luarocks
Whenever `ctx:iteration()` is called, when the PropertiesChanges signal is
emitted, awesome reports a problem with data left in the Lua stack:
```
2017-04-11 07:08:52 W: awesome: a_glib_poll:372: Something was left on the Lua stack, this is a bug!
-------- Lua stack dump ---------
3: nil
2: userdata #16 0x2251a78
1: userdata #320 0x27c5408
------- Lua stack dump end ------
```
This may eventually result in crashes or freezes. To fix the problem, don't use
the GLib context, instead:
- grab all properties from the proxy and copy them over into a table
- use that table as the data for the widget
- update the table when the PropertiesChanged signal is emitted
Stefano Mazzucco