Add dynamic handling of play/pause state in bottom controls bar

[paatre]

This is the implemenation of the issue described in #29.

Regarding the implementation:

1. There was no style guide on contributing to the project so I assumed there was an 80 character limit which is why I didn't just add the handling of the state inside the first controls variable's array.
2. I noticed the container sizing would have broken if I didn't add the single whitespace as padding to the ["[p]", "lay "]. That doesn't look great and would like a more proper padding/whitespace calculation logic but didn't think it was worth consuming time for that when this version also works. I just don't like it.
3. Used the same arguments ordering in the function signature as with components::action and components::progress_bar: &player first, width second.

Here's how the controls looks in the terminal:

$ ./target/release/lowfi
┌─────────────────────────────┐
│ playing Feel The Same       │
│  [////       ] 00:50/02:03  │
│ [s]kip    [p]ause    [q]uit │
└─────────────────────────────┘

$ ./target/release/lowfi
┌─────────────────────────────┐
│ paused Feel The Same        │
│  [//////     ] 01:11/02:03  │
│ [s]kip    [p]lay     [q]uit │
└─────────────────────────────┘

[talwat]

That doesn't look great and would like a more proper padding/whitespace calculation logic

There's already some logic which deals with resizing, but I think having play & pause change positions would be really jarring, so in my opinion the added whitespace is the best solution.

Aside from that it looks good to me, although if you know of some small library to do all of the spacing it would help. The reason I pretty much DIY'd the frontend was because I don't want it to totally take over your terminal by default, but just to be a little section of it, which is why it's like that.

Also, if I may ask, were there any parts of the code which you found a bit confusing? I do try my best to comment when necessary, but I would still appreciate some feedback 😄

[paatre]

There's already some logic which deals with resizing, but I think having play & pause change positions would be really jarring, so in my opinion the added whitespace is the best solution.

👍🏻

Aside from that it looks good to me, although if you know of some small library to do all of the spacing it would help.

This was my first time touching or doing anything with Rust so no, I don't have no clue about any libraries but if at some point I'll have the motivation to check what is out there, I'll let you know. 🙂

The reason I pretty much DIY'd the frontend was because I don't want it to totally take over your terminal by default, but just to be a little section of it, which is why it's like that.

Using small real estate from the terminal screen is pretty ok. I tend to use tmux so having lowfi taking just what it needs is actually pretty great. I can do something like this:

There's a lot of of space left for everything else. 👌🏻

Also, if I may ask, were there any parts of the code which you found a bit confusing? I do try my best to comment when necessary, but I would still appreciate some feedback 😄

Even though this my first time touching a Rust repository, it was actually pretty easy to get hang of how it all works so creating the PR wasn't a big deal at all.

One thing what I'd suggest is not the code but the project directory. For example, there are:

• player.rs, play.rs, and player/ at the same tree level
• inside player/ there's ui.rs and ui/ (which contains components) at the same tree level

It's possibly better to have these organized with some more thought so that it's more clear what everything contains. If I had the say, I would probably split all the different components into their own files and rename ui/ as components/, or have the components.rs at the same level as the ui.rs.

That's my 2c. 😄

[talwat]

One thing what I'd suggest is not the code but the project directory. For example, there are:

• player.rs, play.rs, and player/ at the same tree level
• inside player/ there's ui.rs and ui/ (which contains components) at the same tree level

Yeah, I totally agree. This is a rust convention, not a me convention. The alternative is either to painfully re-export everything in ui.rs from ui/ui.rs or something along those lines, or use mod.rs files which are annoying to deal with in editors.

The way I interpret Rust's methodology is that ui.rs is the main logic of the ui module, with ui/ being extras that aid the functionality of the parent module, in the same way downloader.rs aids player.