playlist (which is currently easily the #1 requested feature). Although
there's still issues to be solved with it, it seems to work pretty well at this
point, I've been running this code for a few days now.
How it works so far:
* You must enable it by selecting "Show Upcoming Playlist" from the View menu.
* When the upcoming playlist is enabled, it takes over control of playback
completely. You can drag-and-drop tracks onto the playlist to add them to
the end of the line, or you can use the context menu's Add to end of upcoming
playlist entry.
* If loop playback is disabled, then entries will be added to the end of the
playlist as entries disappear.
* Hitting Next (or double-clicking an item while a track is playing) will cause
the currently playing track to disappear. The History playlist doesn't play
too well with the upcoming playlist yet, so if you want to keep the songs you
played, you're better off making a normal playlist.
* On that note, double-clicking a song will add it to the beginning of the
queue and immediately start playing it.
* Random play should work as normal. If it doesn't, it's a bug.
* When the list becomes empty, playback stops.
* There is also a selection in the Settings menu, "Save Upcoming Tracks", which
will save the current status of the upcoming playlist on exit.
This is a rather sizeable re-organization/addition of code, so if you
experience crashes/bugs in the next few days, PLEASE report them, and you can
probably assume it's my fault. =D
This feature will probably be tweaked over the next few days as well, but I
wanted to get it out there for testing.
I'm closing bug 63260 since this implements the feature. If you'd like to
quibble on the specifics, feel free to continue commenting on the bug, I'll add
myself to the CC: list for it.
CCMAIL:63260-done@bugs.kde.org
svn path=/trunk/kdemultimedia/juk/; revision=338993

into two separate columns and make it such that only one of them can be
visible at a time. This is more usable, actually works and is saved and
restored properly.
CCMAIL:85130-done@bugs.kde.org
svn path=/trunk/kdemultimedia/juk/; revision=335765

these things internally. This keeps JuK from spawning loads of TRM processes,
makes it such that it's not using the TRM tool (which wasn't ever intended for
application use), gives an appropriate place to change the string for
when the server is under heavy load (but wasn't touched because of the string
freeze) and will make it easy to only popup one dialog at a time (that will
come tomorrow). No strings were added or changed, though some were moved
around.
CCMAIL:66721-done@bugs.kde.org
CCMAIL:65219-done@bugs.kde.org
CCMAIL:86413@bugs.kde.org
CCMAIL:79652@bugs.kde.org
svn path=/trunk/kdemultimedia/juk/; revision=335381

Fix bug 83945 by only skipping the tag editing operation from the inline editor if every tag is identical to the edit text, instead of just checking the one track that was edited.
CCMAIL:83945-done@bugs.kde.org
svn path=/trunk/kdemultimedia/juk/; revision=334042

files with the tag editor widget.
Also, a subtle bug was fixed where retagging multiple files could fail
sometimes if one of those files was in a read-only directory.
CCMAIL:86248-done@bugs.kde.org
svn path=/trunk/kdemultimedia/juk/; revision=334031

anything besides the Normal Playlist) would eventually cause a crash if that
Playlist contained the currently playing file.
I took the lead of the code that detects this in the normal playlists and
left the player going when this happens.
svn path=/trunk/kdemultimedia/juk/; revision=333128