devsnd / cherrymusic

Stream your own music collection to all your devices! The easy to use free and open-source music streaming server.
http://www.fomori.org/cherrymusic
GNU General Public License v3.0
1.03k stars 187 forks source link

Drag and drop to recursively add songs to playlists #522

Open j0ack opened 9 years ago

j0ack commented 9 years ago

Hi,

First thank you for this cool music player.

As mentioned in issue #415 I think it would be great to drag and drop folders in the playlist to recursively add songs to playlist instead of using the "Add all recursively" button.

I would gladly contribute trying to develop this feature. Any hints on how to start would be great.

tilboerner commented 9 years ago

@6arms1leg: the need info tag is meant to signal that we need more information to resolve an issue. Bad naming on my part, I'll try to find a better wording.

@j0ack:

It's great that you'd like to contribute! Developing this feature would be a somewhat involved undertaking in our organically grown codebase, certainly more than a night's work. My suggestion would be to develop it sequentially as two separate features: one is the ability to drag and drop (only tracks for starters), the other is the ability to recursively add folder objects as discussed in #415. Then, combine.

Our wiki's development page has some initial pointers on how things work. As for drag'n'drop, https://jqueryui.com/droppable was suggested in this comment, so that might be worth looking into.

I think a lot of the functionality needed for recursive adding is already implemented experimentally in the lazytrack branch, although I'm not sure what needs to be done at this point to merge it into devel. (I'm ashamed to say I've never really checked it out. :eyes:) @devsnd probably has some more insights, but he's quite busy currently and I don't know when he'll get around to write an answer. For the time being, here's a diff of the branch which should provide some good locations to start exploring from.

We'd be happy if you want to go ahead and get involved. Given the scope of the task, I think it would be a good idea to create an extra branch to work in and start a pull request from, also giving us a place for discussion. Why don't you look around some and let us know if you'd like to give it a go? We can go into more detail from there; it will probably lead you to some specific questions, and here's the place to ask them. :)

j0ack commented 9 years ago

Hello @tilboernern, thank you for your answer, I will check the lazytrack branch and the wiki to see how to start.

About the ability to drag and drop entries, do you think it should replace the current track click selection or the two selection mode should work together ?

I'll keep you informed about my progress, I think I'll give it a try

tilboerner commented 9 years ago

I'll keep you informed about my progress, I think I'll give it a try

Great! Let us know if you hit any obstacles.

About the ability to drag and drop entries, do you think it should replace the current track click selection or the two selection mode should work together ?

The way I see it, drag and drop gives extra control over where exactly a track will be placed, while single-click is a shortcut to add it to the end of the playlist currently in the foreground (the "editing playlist"). The latter is especially useful on small screens, when that playlist and the track might not be visible simultaneously. So I think both modes should work.

However, this would limit our options to use gestures for other things like multiselection-after-longclick. So I'm curious to know what y'all think. @j0ack, @6arms1leg, @devsnd?

6arms1leg commented 9 years ago

Personally, I don't care much about drag and drop. Simple tasks should work without this functionality, in my opinion. Adding a track to the current playlist is probably the most common use case (and should therefore be easy and fast to accomplish), so I think the current single-click behavior is fine.

j0ack commented 9 years ago

Thank you all for your feedbacks.

The way I see it, drag and drop gives extra control over where exactly a track will be placed, while single-click is a shortcut to add it to the end of the playlist currently in the foreground (the "editing playlist"). The latter is especially useful on small screens, when that playlist and the track might not be visible simultaneously. So I think both modes should work.

I agree with that, I think DnD support can give extra control to the user to add a new track and sort his playlist in the same action.

However, this would limit our options to use gestures for other things like multiselection-after-longclick. So I'm curious to know what y'all think

For now JQuery UI draggable does not work on touch devices ( http://forum.jquery.com/topic/jquery-ui-and-touch-devices ) so I think this new functionnality would not limit gestures such as taphold.

Personally, I don't care much about drag and drop. Simple tasks should work without this functionality, in my opinion. Adding a track to the current playlist is probably the most common use case (and should therefore be easy and fast to accomplish), so I think the current single-click behavior is fine.

I think adding this kind of functionnality can be a little more friendly. I agree that adding track is a common use case and should remain simple. That's the reason I was wonderig if the DnD should replace or work with current single-click behavior. I agree to both your answers and will keep it in mind while developping.

j0ack commented 9 years ago

Hi everybody,

I made my first commit this week end about enabling drag and drop on music files as you can see in this diff.

I took a look in the lazytrack branch to see how it had been implemented. Instead of having all the files displayed in the playlist, only one entry "ALL TRACKS IN ... " is appended. Is this the concept of track generator you were talking about in #415 ? I try to find an elegant way to make it user friendly. Any hints are welcome.

EDIT: I just noticed that I have a indentation issue in the JavaScript files, I'll fix that in my next commit.

devsnd commented 9 years ago

Hey @j0ack!

Great to see this coming along. I am a great fan of drag'n'drop, but I've never gotten around to implement it.

As you said, the lazy track branch was exactly the idea that you could have infinitely long playlists without the server nor the client crashing; I've never gotten around to clean it up or to make it work great, so that's that.

Anyway, I guess you are right from a usability stand point that a playlist generator is hard to understand. Maybe implementing infiniscroll on top of the playlist generator would make sense.

j0ack commented 9 years ago

Hi @devsnd

Thanks for your feedback and glad that you're interested by the dnd feature.

I'll look into infiniscroll to see if I could easily implement it on top of playlist generator.

For now the tracks are added using JavaScript and then metadata is loaded from the server. What do you think, in the case of adding multiple tracks at once, about loading tracks and metadata at the same time ? Would it take too much time for the server to handle request ?

devsnd commented 9 years ago

I think that fetching multiple meta infos in one HTTP call would be great for servers with a lot of computing power, but on less beefy machines this leads to a complete blocking of the ui until the info has been parsed. so I'd rather leave it as it is and accept the HTTP overhead for now

On April 17, 2015 8:31:35 AM CEST, j0ack notifications@github.com wrote:

Hi @devsnd

Thanks for your feedback and glad that you're interested by the dnd feature.

I'll look into infiniscroll to see if I could easily implement it on top of playlist generator.

For now the tracks are added using JavaScript and then metadata is loaded from the server. What do you think, in the case of adding multiple tracks at once, about loading tracks and metadata at the same time ? Would it take too much time for the server to handle request ?


Reply to this email directly or view it on GitHub: https://github.com/devsnd/cherrymusic/issues/522#issuecomment-93909117