Version: (using KDE 3.1.9) Compiler: gcc version 2.95.4 20011002 (Debian prerelease) OS: Linux (i686) release 2.4.20 I have different categories of playlists like "pop-1", "rock-3", "classic-2". Depending on my mood I now would like to mix these playlists, e.g., I want to convince juk that it should play random songs from one of the three playlists. Of course I could merge them by hand, but I would prefer it much more if I could check different playlists on the left hand side menu.
Hmm, this would be possible. For example, one could select multiple playlists in JuK by keeping the Ctrl key pressed while selecting items, much like you select multiple playlist items at once. The question is: which actions should be applied to the big, "merged" playlist, and which should stay valid only for the currently viewed playlist? Like, assuming I merged two playlists, should pressing "Next" in one playlist get me to the first song in the next playlist, or to the first song in the current playlist?
> For example, one could select multiple playlists in JuK by keeping the Ctrl key > pressed while selecting items, yup, this is exactly what I meant. > The question is: which actions should be applied to the big, "merged" > playlist, and which should stay valid only for the currently viewed playlist? Good question. I don't have juk to my disposal at the moment, but IMHO "next", "previous" and "random" should work as expected. For instance "Next" gets you to the next song within the playlist until one reaches the last element of the playlist--in this case "next" gets the first song of the second list and so on. A more advanced alternative would be allowing to add playlists to a container. For instance if A, B are playlists, then it should be possible to create a playlist C which contains playlists A and B. C would contain only two entries A,B (and not the songs which are contained in A, B) such that changing items in A or B would have an effect if playing playlist C.
Subject: Re: playing more than one (merging) playlists Ok, thinking about this: *) If you select multiple playlists a new playlist is created (this is an implementation detail actually -- this wouldn't be obvious to the user) *) If the user attempts to modify this playlist -- i.e. adding or removing files, it prompts the user for a name for the playlist -- since these operations would be ambiguous in a "joined playlist" How does that sound? Somewhere in the pending vfolder stuff your request for a dynamic "playlist set" might show up. But at some point I'll have to make a call for what really makes sense there and what doesn't...
> *) If you select multiple playlists a new playlist is created (this is an > implementation detail actually -- this wouldn't be obvious to the user) sounds to me similar to the search folder implementation in kmail (if you do a search in kmail the result is stored in an extra folder). > *) If the user attempts to modify this playlist -- i.e. adding or removing > files, it prompts the user for a name for the playlist -- since these > operations would be ambiguous in a "joined playlist" Hope I understand this correctly: when choosing different playlists the "super list" (or whatever this is called) is the addition of all the lists. The result is stored in a (to the user visible) extra playlist. In order to add /remove further songs I have to duplicate/rename this special playlist first, right? I like the idea, it sounds that it is easy to use and powerful :-) One thing, I am not sure about is what happens if the user changes adds some song to playlist A, where A and B are playlists and Sr (special, after renaming) is Sr = A + B. Will this also modify the result of Sr or not? Sometimes it is nice to have an automatic update, e.g., I have stored my favourite rock songs in a playlist "rock", favourite alternative music in playlist "alt" etc. Of course if I create Sr = { rock, alt } and later add an song to rock I would be happy to automatically have it in my special folder Sr. Probably this thing comes down to the question how this is handled internally. Automatically updating would mean that a playlist is a list element, that means that it is possible to add a playlist to a playlist. There should be a difference between adding a playlist and adding the content of a playlist. Clicking on Sr should show the playlists which were added to it and not the content of these playlists (otherwise we open the box of pandorra, because deleting a song then really becomes a mess). I understand that this is probably getting too complicated for the next version, therefore let's forget about the "handle a list as an list element" thing. If I have later have the time I probably can implement that on my own, there is a nice concept for making a list also a list element (or perhaps this already works this way?).
Subject: Re: playing more than one (merging) playlists Quoting Marco Krohn <marco.krohn@gmx.de>: > sounds to me similar to the search folder implementation in kmail (if > you do a search in kmail the result is stored in an extra folder). Well, sort of. Actually I probably shouldn't have mentioned the creation of an extra playlist since this isn't something that the user would see. Basically what would happen, technically speaking, is that you would click on two playlists. When you select two, JuK needs a place to store the merged results. But in the playlist list (the thing on the left) it would still just show that you have the two playlists selected. > Hope I understand this correctly: when choosing different playlists the > "super list" (or whatever this is called) is the addition of all the lists. The > result is stored in a (to the user visible) extra playlist. In order to add /remove further songs > I have to duplicate/rename this special playlist first, right? Well sort of. It wouldn't be an extra user visible list. But when you tried to do something to this merged list that would require it to act like a normal playlist, it would popup a message box with something like, "You currently have multiple playlists selected, in order to complete this action, a new playlist must be created. [prompt for name]". > One thing, I am not sure about is what happens if the user changes adds > some song to playlist A, where A and B are playlists and Sr (special, after > renaming) is Sr = A + B. Will this also modify the result of Sr or not? Well, since in the above scenario, unless you modify the "merged" playlist, it would just be temporary (only existing as long as you have those playlists selected), yes, if you added something to "A" or "B" and then selected those two playlists again, the contents would be merged on the fly. > Sometimes it is nice to have an automatic update, e.g., I have stored my > favourite rock songs in a playlist "rock", favourite alternative music in playlist > "alt" etc. Of course if I create Sr = { rock, alt } and later add an song to rock I > would be happy to automatically have it in my special folder Sr. > > Probably this thing comes down to the question how this is handled > internally. Automatically updating would mean that a playlist is a list element, > that means that it is possible to add a playlist to a playlist. There should be a > difference between adding a playlist and adding the content of a playlist. Clicking on Sr > should show the playlists which were added to it and not the content of these > playlists (otherwise we open the box of pandorra, because deleting a song then really > becomes a mess). Having a playlist that includes a playlist wouldn't be that hard to implement technically -- it's more of a question of what I can do to make this intuitive in the GUI. Again, adding and removing items becomes ambiguous (and as such confusing, no matter what behavior I was to decide on). But really, this is a separate issue from the above. Before 2.0 I'll be doing some work on vfolders and I'll have to think of solutions to things like this. None of these things are that technically complicated -- it's more a matter of coming up with an intuitive way of presenting these features to the "normal" user (i.e. one that I haven't had to explain it to ;-) ) > I understand that this is probably getting too complicated for the next > version, therefore let's forget about the "handle a list as an list element" > thing. If I have later have the time I probably can implement that on my own, there is a nice > concept for making a list also a list element (or perhaps this already works this > way?). Well, there's a lot of time before the next major release (2.0) -- that will probably come with KDE 3.2, but that's probably at least 6-12 months away. I might release a JuK 1.2 if I find enough bugs in 1.1, but the 1.x series is only bug fixes, not new features. And again, the main issue here isn't technical -- a requirement for new features is an intuitive way to present them to the user, and I'm not convinced that such is possible with this. But I'll do some thinking about it in the coming months. I'll try to get the first case (selecting multiple playlists) implemented in the next week. Cheers, -Scott
> the main issue here isn't technical -- a requirement for new features is an intuitive > way to present them to the user, I absolutely agree with you. > I'll try to get the first case (selecting multiple playlists) implemented in the next > week. sounds very good to me, thanks :-)
Subject: kdemultimedia/juk CVS commit by wheeler: Make it possible to select multiple lists and merge them on the fly. CCMAIL:56258-done@bugs.kde.org M +2 -0 collectionlist.h 1.25 M +3 -3 playlistbox.cpp 1.32 M +1 -1 playlistbox.h 1.27 M +9 -5 playlistitem.cpp 1.32 M +8 -0 playlistitem.h 1.28 M +34 -6 playlistsplitter.cpp 1.70 M +4 -0 playlistsplitter.h 1.55