* MPRIS: Restructured existing implementation
My pr addresses some of the inconsistencies in ncspot's mpris
implementation. While the previous logic was technically good enough, it
was inflexible and reported redundant information.
This will make it easier for software, that processes mpris events in
some way, to accurately react to player updates.
- 'Metadata' and 'Playback' updates have been separated into there own
command
- Mpris commands are only emitted from within spotify.rs
- Some parts of the application creation logic has been
restructured to allow for mpris events to be emitted upon startup
- The initial song loading code has been moved from 'Queue::new'
into 'Application::new'.
* MPRIS: implemented most clippy suggestions
* Fix: applied clippy suggestions + format
* MPRIS: Renamed MprisCommands to be more resonable
I've added a clippy exception so it does not complain to us about enum
variants starting with the same prefix.
---------
Co-authored-by: haruInDisguise <--help>
Instead of crashing on Termux, no IPC socket is created. This is a
temporary solution until a suitable runtime directory for the Termux
platform can be found.
Each user has their own runtime directory at `/run/user/<uid>`. Creating
the IPC socket in there makes sure it is cleaned up regardless of
whether `ncspot` exits normally.
BREAKING CHANGE: move IPC socket location
Instead of trying to handle signals for every step of the `cursive`
event loop, move the signal handling into its own asynchronous task and
send callbacks to `cursive` when a signal arrives.
The `lazy_static` crate was superseded by the `once_cell` crate which
has been included in Rust's standard library since version `1.70`.
Remove the `lazy_static` dependency and refactor all use cases to use
`std::sync::OnceLock` instead.
Co-authored-by: Henrik Friedrichsen <henrik@affekt.org>
To have a clear distinction between code dealing with OS process
characteristics and code of ncspot itself, it makes sense to move the
async runtime together with ncspot as it doesn't have anything to do
with the OS process.
Some applications move their 'global' data into a struct called `App` or
`Application`. This makes it very clear what data belongs to the
'global' scope or in other words, to the application itself.
