As correctly pointed out by @rrhuffy, restricting update intervals to
minutes is pretty arbitrary. Therefore, change logic to specify updates
intervals in *seconds*.
Also, to maintain backwards compatibility for users that already have
custom intervals in their config, allow a module to specify their own
"factor" for intervals. So a module that expects the interval to be in
minutes can set the factor to 60.
Some cities (e.g. in different countries) have the same names. Providing a city
name to the weather module would previously display the first returned result by openweathermap's API.
This commit allows city ids to be provided to the weather module. If a location passed
to the weather module only contains numbers, it will be interpreted as a city id.
City ids are those handled by openweathermap's API to uniquely identify cities.
See https://openweathermap.org/current#cityid for details.
If multiple locations are provided as comma-separated list, left-click
and right-click can be used to circulate through them.
NOTE: Every click produced a new request to the weather reporting
service!
see #360
Use generic interval mechanism in most of the modules that use slow
updates.
Only exception: getcrypto, as the interval is specified in seconds there
and I want to retain backwards-compatibility.
fixes#220
If data cannot be retrieved for some reason (be pretty generous about
that by catching generic exceptions), instead of terminating the whole
status bar, simply report unknown data.
see #110
Since requests works the same for python2.7 and python3.x, use requests
instead of urllib (which returns a string in python2.7, but byte data in
python3.0, at least).
* Use app-specific API key for bumblebee-status
* Add some parameters (location, unit, update interval)
* Make interval calculation based on time, not number of calls
