Reimplement a library

[danirabbit]

Ah before you get too far here, I might already be late :sweat_smile:, but instead of watching music directories ourselves it might make sense to lean on Tracker here

[leolost2605]

Tracker as in GNOME Tracker? Also don't worry that was mostly copied and pasted from Videos :)

Also would this be something that generally might get accepted? I personally definitely prefer to play my music without having to drag and drop between files and music so I thought I might just get a little proof of concept :). However I've seen considerations to keep music with a queue only...

[danirabbit]

@leolost2605 Yeah exactly. It seems like it would make sense to replace individual library stuff in each of these media apps with just one indexing service. Especially if we end up using it for search in Files, then we're not trying to index the same files over and over again across apps

Yeah, I think there's demand for having some kind of local library view! It just brought quite a lot of problems in the old Music with performance and cases like external media etc. @jeremypw might be someone to ask about pitfalls since I think he spent some time trying to fix some of those issues

[zeebok]

I would definitely appreciate a library since I am an old goat and still have music downloads thanks to Bandcamp! I take it Tracker might also be something that would need to be looked into for Photos getting a revamp?

[leolost2605]

It's updated now to use tracker, still needs some work though. Regarding performance: This uses GTK4's ListView which is AFAIK a miracle worker in improving performance at least on the toolkit side. As we are using tracker I think the backend shouldn't be a big problem either. Still if someone has some do's and don'ts I'd be glad to hear them.

Meanwhile it would probably be good to roughly know which direction the UI should go in. The current prototype looks like this: I also had a version where the play queue was accessed only using a little icon button in the top right corner of the main view but I like this one quite a lot better. Also maybe for the future: Should we keep this layout (which I actually quite like especially when we make it adaptive how clean it would look then) or go back to a more traditional one with the player at the bottom only as a bar or something similar?

[danirabbit]

@leolost2605 in terms of UI I think it would make more sense to swap the Now Playing view and the play queue or to be able to reveal the queue inside the now playing view. Especially to be able to drag and drop tracks into the queue for example. I'll try to do some mockups or prototypes soonish, but trying to prioritize OS 7.1 release currently :)

[danirabbit]

I think a big mistake we made in the old music that I don't want to repeat here is having multiple play queues. So what I'm noticing with this branch is the library is being treated as a separate play queue. Instead I think the way to go is that if you start playing a track from another view, whatever is in that view gets added to the play queue. So the play queue always accurately reflects what is now playing and playing next and can be trimmed or expanded upon or re-arranged etc. In the current branch for example, once you start playing from the library there's no way to shuffle, and if there was, there's no way to see what song would be playing next. But if we added all of the tracks to the play queue, those features would be available.

There's also the problem of in the current branch you can add things to the play queue and then start playing from the library. So what the play queue claims is up next, what it claims the shuffle state is, etc is all inaccurate now

[leolost2605]

@leolost2605 in terms of UI I think it would make more sense to swap the Now Playing view and the play queue or to be able to reveal the queue inside the now playing view. Especially to be able to drag and drop tracks into the queue for example. I'll try to do some mockups or prototypes soonish, but trying to prioritize OS 7.1 release currently :)

Sounds good @danirabbit! By the way I currently have a lot of free time as I finished school last month and am planning to study computer science which starts not until october so if you want you can assign me to some issues (because sometimes I don't know what should be prioritized) and I'll try my best to solve them which gives me good practice and elementary hopefully some progress - so win win :)

[leolost2605]

I think a big mistake we made in the old music that I don't want to repeat here is having multiple play queues. So what I'm noticing with this branch is the library is being treated as a separate play queue. Instead I think the way to go is that if you start playing a track from another view, whatever is in that view gets added to the play queue. So the play queue always accurately reflects what is now playing and playing next and can be trimmed or expanded upon or re-arranged etc. In the current branch for example, once you start playing from the library there's no way to shuffle, and if there was, there's no way to see what song would be playing next. But if we added all of the tracks to the play queue, those features would be available.

There's also the problem of in the current branch you can add things to the play queue and then start playing from the library. So what the play queue claims is up next, what it claims the shuffle state is, etc is all inaccurate now

I agree adding everything to the play queue would probably be the most logical way of doing it. With the current approach I wanted to mimic what I think most players currently do (e.g. spotify, amazon music, etc.) that is if you start a song from a e.g. playlist or in this case library that will be continued and if you go to your queue that will be continued.

[leolost2605]

AFAIK our version of Tracker (3.3) is currently pretty much broken when using from flatpaks with moderately sized requests. I'll try to find some more workarounds but we might have to delay this until OS 8