Version: (using KDE Devel) Installed from: Compiled sources OS: Linux The newly introduced Play Queue is a great step forward, but there are several problems with it: 1. In the past, I could double-click Collection List and songs would be played endlessly, but now only 15 items are added to the Play Queue. When these items finished playing, I have to double-click Collection List again in order to hear more songs. This behaviour is very annoying, as you can not leave your PC alone. Because of this, I marked this report as a bug and not as a wish (it previously worked right). Suggestion: After a song has finished playing, add a new one to the end of the Play Queue. The song should be taken from the same folder/playlist which was previously double-clicked. 2. If a custom playlist is double-clicked, only the items from that playlist should be added to the Play Queue. This was also the former behaviour: You double-clicked a playlist and the songs from that playlist were played endlessly. 2b. Maybe the Play Queue should be cleared and the current song stopped when double-clicking a playlist as this probably means that the user wants to listen to the playlist immediately. 3. While browsing the Collection List, I often see an interesting song which I want to be played soon, so I drag it into the Play Queue. The problem is that the Play Queue often contains many queued songs, so I have to wait a long time until I hear that song. Suggestion: If you drag a song over the Play Queue and wait a second or so without dopping it, the Play Queue should be opened in the right view (song list?) so one can drop it into the desired position there. 4. The blue arrow button in the button right corner is almost useless now, as it always jumps in the Play Queue. I often use that button as a shortcut to the place in the Collection List, to see the other songs from that artist/album. Suggestion: Jump to the correct entry in the playlist which was previously double-clicked (of course only if there actually IS a double-clicked playlist). 5. Clearing a song from the Play Queue should make the song stop. 6. Dropping a song into an empty Play Queue should start it immediatley. That's all what came into my mind now, maybe I'll add something later. Thank you for this great application and the good support (the bugs I reported earlier were fixed within 24 hours!!)
Bug 88888 ! Do I win something now? (Sorry for the useless comment, I just wanted to point that out)
> 1. In the past, I could double-click Collection List and songs would be > played endlessly, but now only 15 items are added to the Play Queue. When > these items finished playing, I have to double-click Collection List again > in order to hear more songs. This behavior (playing endlessly) only occurred if Loop Playlist was enabled. The Play Queue is supposed to play endlessly if you have Loop Playlist enabled as well. > 2. If a custom playlist is double-clicked, only the items from that > playlist should be added to the Play Queue. This was also the former > behaviour: You double-clicked a playlist and the songs from that playlist > were played endlessly. This is a regression I have been meaning to fix. =D > 2b. Maybe the Play Queue should be cleared and the current song stopped > when double-clicking a playlist as this probably means that the user wants > to listen to the playlist immediately. I don't really like this much actually. > 3. Suggestion: If you drag a song > over the Play Queue and wait a second or so without dopping it, the Play > Queue should be opened in the right view (song list?) so one can drop it > into the desired position there. I love this suggestion, I hope it's not hard to implement. > 4. Suggestion: Jump to the correct entry in the playlist which > was previously double-clicked (of course only if there actually IS a > double-clicked playlist). Scott has noticed this also, but I've been slacking fixing it. :-( > 5. Clearing a song from the Play Queue should make the song stop. OK. > 6. Dropping a song into an empty Play Queue should start it immediatley. I'm not so convinced on this one, but I'll run it past Scott and if he likes it I'll do it anyways. > Thank you for this great application and the good support (the bugs I > reported earlier were fixed within 24 hours!!) Well that's because they were easy. ;-) Just remember though, the Play Queue wasn't added for everyone to use. If after I fix everything you're still not satisfied with its behavior, remember that you can disable the Play Queue.
On Sunday 05 September 2004 22:02, Michael Pyne wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=88888 > > > > > ------- Additional Comments From michael.pyne kdemail net 2004-09-06 > 00:02 ------- > > This behavior (playing endlessly) only occurred if Loop Playlist was > enabled. The Play Queue is supposed to play endlessly if you have Loop > Playlist enabled as well. You are right, it just enabled Loop Playlist and this works fine. However, if Loop Playlist is disabled and the Play Queue hidden, the songs are still played endlessly after double-clicking Collection List. I thought that Loop Playlist means if all songs from the playlist are played, the same songs are then played again (->looped). The behavior of the Play Queue without Loop Playlist seems to be that 15 items are added to the queue and they are all played without adding new ones. It should be: If a song finished playing AND there are still unplayed items in the active playlist, add one of these unplayed songs to the end of the Play Queue. With Loop Playlist it should be the same behavior, but after all songs from the active playlist are played, they should again be marked as unplayed so they can reoccur in the queue. What I'm trying to say that the behavior should be the same regardless if Play Queue is enabled or not. Hope I was right and could make myself clear here. > > 2b. Maybe the Play Queue should be cleared and the current song > > stopped when double-clicking a playlist as this probably means that > > the user wants to listen to the playlist immediately. > > I don't really like this much actually. Well, IMHO at least the auto-generated entries (the entries that weren't dropped there by the user) in the queue should be cleared. If I double-click a playlist, I don't want to listen to the rest of the 15 songs from the previously active playlist. But you are right that the current song shouldn't be stopped. > Just remember though, the Play Queue wasn't added for everyone to use. > If after I fix everything you're still not satisfied with its behavior, > remember that you can disable the Play Queue. I won't disable it. Usually I just let Juk play random songs from the Collection List or my "Favorites" playlist, but when I am in the mood for a few specific songs, I'll add them to the queue. So the Play Queue is really useful from time to time (at least if point 3 is implemented). Great to hear that you are working (or considering to) on the other points. I've noticed another thing : 7) If the Play Queue is enabled, double-clicking the Collection List right after starting Juk results in the FIRST song (always) of the Collection List being played (even with random play). The next songs queued seem to be random, as expected. P.S. Can I safely strip the header ("You are receiving this mail ..." and the rest) when replying via e-mail so that it will still show up in bugzilla ?
Some minor addition to point 3: Open the Play Queue immeditaly if shift is pressed while dragging (for the impatient) And yet another thing: 8) Add to Play Queue (button in context menu): Do not add the song to the end of the queue, but after the currently playing song and after all other manually dropped/added songs. This is useful if there are about 15 automatically queued songs, which should play after the songs manually added to the queue. It's reasonable: If you add songs to the play queue using that button, you expect them to play soon. You certainly don't want to hear about 15 other songs which Juk queued there itself. Dropping a song in the queue should have the same effect: automatically generated entries should be placed after the dropped song.
CVS commit by mpyne: Automatically switch to the destination playlist if you hover over the playlist icon for a moment during a drag-and-drop operation. This allows you to drop the playlist items in the appropriate place in the destination (especially useful for the Play Queue). CCMAIL:88888@bugs.kde.org M +1 -0 playlist.cpp 1.255 M +2 -0 playlist.h 1.139 M +24 -0 playlistbox.cpp 1.125 M +4 -0 playlistbox.h 1.69 --- kdemultimedia/juk/playlistbox.h #1.68:1.69 @@ -107,4 +107,7 @@ private slots: void slotPlaylistDestroyed(Playlist*); void slotSavePlaylists(); + void slotShowDropTarget(); + + void slotPlaylistItemsDropped(Playlist *p); void slotAddItem(const QString &tag, unsigned column); @@ -122,4 +125,5 @@ private: bool m_treeViewSetup; Item *m_dropItem; + QTimer *m_showTimer; DynamicPlaylist *m_dynamicPlaylist; }; --- kdemultimedia/juk/playlistbox.cpp #1.124:1.125 @@ -56,4 +56,5 @@ PlaylistBox::PlaylistBox(QWidget *parent m_treeViewSetup(false), m_dropItem(0), + m_showTimer(0), m_dynamicPlaylist(0) { @@ -148,4 +149,7 @@ PlaylistBox::PlaylistBox(QWidget *parent // Auto-save playlists after 10 minutes QTimer::singleShot(600000, this, SLOT(slotSavePlaylists())); + + m_showTimer = new QTimer(this); + connect(m_showTimer, SIGNAL(timeout()), SLOT(slotShowDropTarget())); } @@ -224,4 +228,5 @@ void PlaylistBox::setupPlaylist(Playlist { PlaylistCollection::setupPlaylist(playlist, iconName); + connect(playlist, SIGNAL(signalPlaylistItemsDropped(Playlist *)), SLOT(slotPlaylistItemsDropped(Playlist *))); if(iconName == "today") { kdDebug(65432) << "Setting up upcoming playlist after Collection List\n"; @@ -360,4 +365,14 @@ void PlaylistBox::slotSavePlaylists() } +void PlaylistBox::slotShowDropTarget() +{ + if(!m_dropItem) { + kdError(65432) << "Trying to show the playlist of a null item!\n"; + return; + } + + playlistStack()->raiseWidget(m_dropItem->playlist()); +} + // For the following two function calls, we can forward the slot*Item calls // to the tree view mode as long as it has already been setup, whether or @@ -412,4 +427,6 @@ void PlaylistBox::decode(QMimeSource *s, void PlaylistBox::contentsDropEvent(QDropEvent *e) { + m_showTimer->stop(); + Item *i = static_cast<Item *>(itemAt(contentsToViewport(e->pos()))); decode(e, i); @@ -462,8 +479,10 @@ void PlaylistBox::contentsDragMoveEvent( if(m_dropItem != target) { Item *old = m_dropItem; + m_showTimer->stop(); if(e->isAccepted()) { m_dropItem = target; target->repaint(); + m_showTimer->start(1500, true); } else @@ -635,4 +654,9 @@ void PlaylistBox::slotShowContextMenu(QL } +void PlaylistBox::slotPlaylistItemsDropped(Playlist *p) +{ + raise(p); +} + void PlaylistBox::slotSetViewMode(int index) { --- kdemultimedia/juk/playlist.h #1.138:1.139 @@ -434,4 +434,6 @@ signals: void signalEnableDirWatch(bool enable); + void signalPlaylistItemsDropped(Playlist *p); + private: void setup(); --- kdemultimedia/juk/playlist.cpp #1.254:1.255 @@ -872,4 +872,5 @@ void Playlist::contentsDropEvent(QDropEv dataChanged(); + emit signalPlaylistItemsDropped(this); KListView::contentsDropEvent(e); }
This bug is a really good one because it addresses all the issues remaining with the Play Queue. Shall I file a separate bug, because at the moment (beta2) when double-clicking a playlist, no songs are added to the play-queue and the first one in the list, i.e. just playing, is restarted. Further I absolutely and fully support the request to erase the play-queue and put all the files in the double-clicked playlist in it. At least, put all those files on top of the play-queue. If I double-click a playlist, I want to listen to those songs instantly and all of them. If I want them added to the playlist I enqueue them using the context-menu. Doing the latter by double-clicking erases the former functionality without adding any new functionality. Enqueuing by double-clicking is totally against normal GUI behaviour, even within JuK. (Double-)Clicking an item executes, i.e. opens it. Best example is the playlist, double-clicking a song does NOT enqueue it but plays it, double-clicking should do exactly the same, i.e. play it now, not enqueue it. This would restore consistency of double-click behaviour again. Enqueuing is done using context-menus. If you want enqueuing to be default, this should have to be set manually in the settings.
I have to describe the bug about double-clicking not adding songs to the play-queue a bit more precise. If there are just a few songs left in the play-queue, double-clicking a playlist adds one song to the play-queue, yet not from the playlist, so it does not even enqueue, where it should start playing a playlist, which is clearly a bug.
CVS commit by wheeler: Ok, more than five hours late and coolo still hasn't turned me into a pumpkin. I've been assured that this will happen in the morning, though after three hours of sleep, I think the effect would be natural. The moral of the story: test features in apps you maintain before the day of the freeze. (I knew that the play queue was broken, but not quite how badly -- this was mostly Michael's turf, but he's away for another few weeks.) Ok, so stuff that happened: Fixed the "magical not-showing-back-up" Play Queue (was related to saving the play queue, which even when set up properly just caused all sorts of crashes. Commented out for now, ideally to be reenabled in 3.4.1) -- #99191 Fixed up a lot of the quirkiness with the interaction of the Play Queue and the rest of the application playlists. This hopefully fixes #98473 (if not, just reopen) Double clicking on an item (anywhere) plays it immediately. #97021 And the catch all, #88888, "this sucks" was mostly implemented. Some of the things I took a different line on, but you got at least 3 of the 6. The last two I don't agree with. If you feel so compelled, open more specific requests from here on out. Basically this structurally changed things so that instead of adding items to the play queue when turned on and always using that as the main location for playing now the play queue is only used when there's stuff in it. When it's empty again playing resumes in the list that the last item in the play queue came from. It will jump back into the play queue as soon as something is added. This is still a little rough, but it doesn't crash all the time like it was before (fixed at least three crashes on this one) and is close enough to actually being releasable for me to now get a couple hours sleep. BUG:99191 BUG:98473 BUG:97021 BUG:88888 M +4 -2 cache.cpp 1.33 M +1 -1 collectionlist.h 1.64 M +1 -1 jukui-rtl.rc 1.8 M +1 -1 jukui.rc 1.59 M +9 -7 playlist.cpp 1.300 M +4 -11 playlist.h 1.157 M +1 -3 playlistcollection.cpp 1.69 M +0 -7 playlistcollection.h 1.38 M +1 -0 playlistitem.h 1.68 M +4 -2 tracksequencemanager.cpp 1.5 M +52 -113 upcomingplaylist.cpp 1.9 M +8 -16 upcomingplaylist.h 1.8
Nice to see some development on Juk again. The changes to the Play Queue look promising, however I noticed a rather major bug. >When it's empty again playing resumes in the list that the last item in the >play queue came from. This does only work with RMB->Add to Play Queue, but not with drag&drop. I am reopening because of this, I hope you don't mind. The bugzilla label says >"Reopen Bug because you have new info (you're the reporter)", and I've got new information. Hope this was the Right Thing to do. BTW, I would prefer another behavior: >When it's empty again playing resumes in the list that was previously >double-clicked. Because everybody probably has his own opinion on this, that would need to be configureable. The reason why I don't like the current behavior is that I, as I already wrote somewhere, always listen to my "Favorites" playlist and rarely add a specific song from the Collection List to the Play Queue. After that song has finished, I now have to listen to all these crap songs which are in my Collection List, instead of continuing with my own playlist. Should I open a bug report (wishlist) for this? Aside from this, I like the new behavior.
> This does only work with RMB->Add to Play Queue, but not with drag&drop. Yes, I know -- this was actually even more broken before, but because of some of the way that the layers work inside of JuK there wasn't a quick fix for this (and actually this one came about 5 hours after the freeze), so that'll have to wait until 3.4.1. > I am reopening because of this, I hope you don't mind. Well, I'm reclosing this one, but feel free to open a new one. Specifically "catch all" bugs like this are annoying to manage in the bug system because there's not a specific point that they're finished or if I disagree with one part or another that's difficult to track. The bug system is mostly designed with the assumption that a single issue is contained in a bug. > Because everybody probably has his own opinion on this, that would need to > be configureable. [...] Well, no -- I don't intend to make this configurable. Your objection is based on a bug (which I intend to fix, but just couldn't get to in time).