Default to using the Awesome theme font in spotify-widget

[chaorace]

This change switches to using the theme font (beautiful.font) instead of 'Play 9'. This change brings the widget more in line with the other awesome widgets, particularly since Play is not used as the default in any other widget.

[streetturtle]

Hi! Thanks for the PR! There was some discussion here and here about not making beautiful a dependency, as it might be initialised after the widget. In order to override the default font, one can set the font parameter to be beautiful.font, what do you think?

[chaorace]

@streetturtle It seems as though beautiful is already a dependency for several other widgets in the package, though? Why are some allowed to use it and not others? Shouldn't a consistent package-wide default be agreed upon before deciding to not use the theme font?

[Aire-One]

AFAIR, the "this library shouldn't use beautiful" comes from https://github.com/streetturtle/awesome-wm-widgets/issues/274.

The main idea is that some well-known libraries like https://github.com/lcpz/lain and https://github.com/lcpz/awesome-copycats enforces a pattern where the user defines the screen decoration (aka the desktop bar and widgets) in the theme.lua file. At this point, beautiful can't be initialized, so it makes all widget with values based on it unusable.

The fs-widget was the first (and only ?) to get the "new pattern" to not depends on beautiful. I'm not very active on this repository, so I don't know how it went after that.

The idea of the "new pattern" I have proposed with https://github.com/streetturtle/awesome-wm-widgets/pull/277 is that the themable-values are taken with the priority waterfall config[prop] = args[prop] or beautiful[prop] or value. It is read as :

1. if the user passes themable-value by function parameters (for example: local w = some_widget({ theme = { bg = "#F00" } })), the widget will use this parameter value,
2. if the parameter is missing (for example because the user did local w = some_widget()), the widget will use beautiful.bg,
3. then if beautiful isn't available (because the theme doesn't define the property, or because beautiful isn't initialized), it'll take the default value as defined by the widget internals.

So beautiful should still be a default for the user in a normal usage (aka not the awesome-copicats pattern).