Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Credits support #526

Merged
merged 11 commits into from
Oct 24, 2024
Merged

Credits support #526

merged 11 commits into from
Oct 24, 2024

Conversation

jacksongoode
Copy link
Collaborator

You can also click on the artists to get to their page!

@jacksongoode jacksongoode mentioned this pull request Sep 25, 2024
@jacksongoode
Copy link
Collaborator Author

@SO9010 Wanted to get this one in but we still need to make sure that clicking credits while there is already a credits window, we don't spawn another.

@SO9010
Copy link
Contributor

SO9010 commented Sep 26, 2024

@jacksongoode I'll have a look at this, but I also think the UI should be consistent with the preferences window if we have a pop-up open. Otherwise, it looks a bit out of place.

Also, I think we should consider changing the order of the right-click context menu. The contexts in the top section are related to going to the track's artist and the album, so maybe we should place it above or below those two contexts.
I also feel that without doing this, people's muscle memory would get in the way of adding the song to their playlist, as that has always been at the bottom.

image
image
Maybe the copy link to track should get moved down to the lower section.
image
However, it could also be ordered as a list of priority to the user, and maybe we could flip it all the way around so that as soon as the user right-clicks on the track, they can add it to a playlist. This could maybe improve UX? Up to you.

@jacksongoode
Copy link
Collaborator Author

jacksongoode commented Oct 7, 2024

I would be happy to go with what you suggest here. I'm indifferent about the location, but it should be logical or follow Spotify? I do feel the default preferences window is a little too big for just the credits, I understand the rational between having them the same size but maybe we can make them the same height and the credits, half the width?

@SO9010
Copy link
Contributor

SO9010 commented Oct 7, 2024

Yeah, having the same height but half the width sounds good to me.

@SO9010
Copy link
Contributor

SO9010 commented Oct 18, 2024

Its looking good now!

@jacksongoode
Copy link
Collaborator Author

There are still two bugs I'd like it figure out. One is that clicking on the credits to each track doesn't reliably make them appear. It seems sometimes the network gets hung up on fetching the credits. And it requires interacting with some other network connection and triggering some fetch to actually cause the credits to work again.

The other thing is that we should only have one credit window at a time where we set the credit window ID and then replace the title and content if that window exists.

Copy link
Contributor

@SO9010 SO9010 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've had a quick look just added my thoughts, I will add some changes that I think would be good.

@@ -38,6 +39,43 @@ use crate::{

use super::{cache::WebApiCache, local::LocalTrackManager};

#[derive(Debug, Clone, Data, Lens, Deserialize)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these structures need to be public? They aren't being called more than once, are they? I think it would make more sense and follow the rest of the code more if we had these in the function that calls the API.

}

#[derive(Debug, Clone, Data, Lens, Deserialize)]
pub struct CreditArtist {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be in the lyrics file, which could then be imported into this file. This is what is usually done.

@@ -84,6 +85,8 @@ pub struct AppState {
pub finder: Finder,
pub added_queue: Vector<QueueEntry>,
pub lyrics: Promise<Vector<TrackLines>>,
pub credits: Option<TrackCredits>,
pub webapi: Arc<WebApi>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused about why we need a new webapi module.

"client-token",
self.session.client_token().unwrap_or_default(),
);
let response = Self::with_retry(|| Ok(request.clone().call()?))?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With_retry actually only applies when error 429 is sent back, which means too many requests have been sent. Is this needed?

@SO9010
Copy link
Contributor

SO9010 commented Oct 21, 2024

I have submitted a pr to the repository for these changes.

@jacksongoode
Copy link
Collaborator Author

@SO9010 Still seeing that the response is throttled? It's pretty odd, not sure if this endpoint is more heavily restricted than others so maybe we need to compensate for that?

@SO9010
Copy link
Contributor

SO9010 commented Oct 21, 2024

It probably is restricted due to being experimental. What happens when it doesn't work? Is there maybe a way to detect it then just block it?

@jacksongoode
Copy link
Collaborator Author

When it doesn't work it just stalls and the window doesn't get refreshed. It's actually really finicky... It also might be a consequence of Psst's inability to repair a broken network connection/get a new token?

@jacksongoode
Copy link
Collaborator Author

Alright I think I've gotten everything in a good state now.

@SO9010
Copy link
Contributor

SO9010 commented Oct 23, 2024

Just checked it looks great!

@SO9010
Copy link
Contributor

SO9010 commented Oct 23, 2024

The only thing that I can think of is perhaps caching this, but I'm not sure it is needed, its quite a fast request anyway with not a lot of information. We could address this later...

@SO9010
Copy link
Contributor

SO9010 commented Oct 23, 2024

@jacksongoode Something that we should apply to all of our serializing where there may not be any data in the field is by having #[serde(skip_serializing_if = "Option::is_none")].

For example in the playlist one there is:
#[serde(skip_serializing_if = "Option::is_none")]
pub images: Option<Vector>,

This would optimize the requests a lot!

@jacksongoode
Copy link
Collaborator Author

Where would you recommend we add that? To all of the credits fields?


#[derive(Debug, Clone, Data, Lens, Deserialize)]
pub struct TrackCredits {
#[serde(rename = "trackUri")]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead using this we should use: #[serde(rename_all = "camelCase")]

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

#[serde(rename = "roleCredits")]
pub role_credits: Arc<Vec<RoleCredit>>,
#[serde(rename = "extendedCredits")]
pub extended_credits: Arc<Vec<String>>,
Copy link
Contributor

@SO9010 SO9010 Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here would could have #[serde(skip_serializing_if = "Option::is_none")]

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I made all the possible credits optional I believe.

@jacksongoode
Copy link
Collaborator Author

@SO9010 How does that most recent commit look to you? If good, I'll merge.

@SO9010
Copy link
Contributor

SO9010 commented Oct 24, 2024

Yes looks good to me!

@jacksongoode jacksongoode merged commit 0292319 into main Oct 24, 2024
8 checks passed
@jacksongoode jacksongoode deleted the jackson/credits branch October 24, 2024 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants