Open mattmahn opened 8 years ago
It appears that the Travis build is failing because it cannot connect to the Docker container's D-Bus. This is a known issue: docker/docker#7459, systemd/systemd#589.
To get around this, we could use an environment variable to detect whether or not it is being tested in a Docker container, then simply not execute that code that deals with the D-Bus (its only in Barr::Blocks::Spotify#initialize).
Thoughts?
Thanks for this @mattmahn. this looks great.
For the test, I'd prefer the DBus connection to be mocked/stubbed rather than it have different behaviours for different environments. It'll keep the tests fast and consistent this way.
This PR will add support for using Spotify as a music player. It works exactly the same as the Rythmbox block.
Since I am not currently using i3/lemonbar, I have not been able to test how well it actually integrates with those. However, I have tested all the other D-Bus and Spotify functionality. The only thing that I think could be a problem is the button controls; those
dbus-send
commands print to stdout, so I'm not sure if that will break lemonbar or i3. When I removed the--print-reply
option, then Spotify would not do what it was supposed to do (i.e. play/pause, etc). I assume that if printing to stdout is a problem,&>/dev/null
could simply be tacked onto the end of the command.Tested with:
P.S. I added
vendor/bundle
to the .gitignore, so people can keep their development and system gem environments separated.