GitLab

svn path=/trunk/KDE/kdemultimedia/juk/; revision=536733

svn path=/trunk/KDE/kdemultimedia/juk/; revision=535912

because of K*Accel

svn path=/trunk/KDE/kdemultimedia/juk/; revision=534462

svn path=/trunk/KDE/kdemultimedia/juk/; revision=518198

again so the names doesn't collide with the ones in libkcddb
where only libmusicbrainz and not tunepimp is needed

svn path=/trunk/KDE/kdemultimedia/juk/; revision=514819

svn path=/trunk/KDE/kdemultimedia/juk/; revision=514529

update.

All source now has a vim modeline, and all files use the same modeline (described in HACKING).

This will make it easier for vim users to stay HACKING-compatible in JuK.

svn path=/trunk/KDE/kdemultimedia/juk/; revision=513935

running my script to remove tabs and extra whitespace at the end of lines.

svn path=/trunk/KDE/kdemultimedia/juk/; revision=513916

svn path=/trunk/KDE/kdemultimedia/juk/; revision=455930

since that's what it's looking for, and I'm about to add a check
for just MusicBrainz in libkcddb

svn path=/trunk/KDE/kdemultimedia/juk/; revision=455853

BUG:103721

svn path=/trunk/kdemultimedia/juk/; revision=406775

svn path=/trunk/kdemultimedia/juk/; revision=392025

This is actually pretty cheap as opposed to QObject based stuff (i.e. QGuardedPtr)
and will probably be useful elsewhere.  This made it possible to pretty easily
knock out a couple crashes.

BUG:99885
BUG:99886

svn path=/trunk/kdemultimedia/juk/; revision=392015

so that we can show the playing track in both playlists.  This is *close* to
working properly (but misses some notable cases like say, the first item).

Also removed a now unused function in Playlist.

svn path=/trunk/kdemultimedia/juk/; revision=362170

when it goes away.

FEATURE:77467

svn path=/trunk/kdemultimedia/juk/; revision=362147

the notion of multiple playing items with the first being the "master"; this
isn't used yet, but has a few places where it should be in JuK.

svn path=/trunk/kdemultimedia/juk/; revision=362096

introduced by the recent patch.

svn path=/trunk/kdemultimedia/juk/; revision=361760

OK - implemented in the compare() function - now coverinfos are sorted based on whether there is a cover or not.

Issue:  It's slower than setting the text (as I had done before)  I think it's because it's checking if there's a cover for each file.  Maybe we should hold within the coverinfo object whether or not there is a cover (so we only check it once...or whenever we add or remove a cover)

CCMAIL: wheeler@kde.org

svn path=/trunk/kdemultimedia/juk/; revision=361564

svn path=/trunk/kdemultimedia/juk/; revision=361552

We need to return something as the text of the Cover column, or else you aren't able to sort by whether the column has a cover or not.  A blank string (QString::null) and a single space (" ") accomplish this.

svn path=/trunk/kdemultimedia/juk/; revision=361531

Remove the unnecessary dependency of filehandle.h on coveritem.h, and correct the files that broke because of this.

This doesn't actually improve compile times after changing coveritem.h that much unfortunately.

svn path=/trunk/kdemultimedia/juk/; revision=361380

are still quite a few rough edges, but interface and codewise, but it's
close enough that those can be worked out in the relatively near future.

FEATURE:60462

svn path=/trunk/kdemultimedia/juk/; revision=361330

things from happening if we rename the file to a name we previously used.

BUG:91503

svn path=/trunk/kdemultimedia/juk/; revision=359731

What this does is introduce a class that manages changes to PlaylistItems.  A number of PlaylistItems can be altered before the underlying files are changed.  Once the files are changed, a record is kept of the changes, which can then be used to undo what happened.  Also, this class takes care of items that are to be renamed.

All code paths that are capable of altering a tag have been changed to use this class.

Note that the underlying code could probably use some cleaning up.  e.g. adding a copy ctor to Tag instead of making a duplicateTag() function. ;-)

I've tested this on a temp directory of copied music, so I'm pretty confident this all works and is safe.  However, you may want to test on a backup first to make sure it works on your system too. =D

Now the question is whether I should backport this or not. :-/

CCMAIL:61340-done@bugs.kde.org

svn path=/trunk/kdemultimedia/juk/; revision=349640

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

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

renaming a file, the map of file names to collection list items wasn't updated,
which caused duplicate entries to appear when the History list added an entry
when you play the newly-renamed file.

Although disabling the KDirWatch doesn't appear to be actually necessary to fix
the bug, I'm leaving that part in because I think that once 85534 is fixed it
will expose the bug again.

svn path=/trunk/kdemultimedia/juk/; revision=332434

in the column and use it for the searches (finally, I can search on my list of
files without tags!)
Also, changed the default value of m_fileColumnFullPathSort to match
the default column title and the previous behaviour (which only showed the
file name)

svn path=/trunk/kdemultimedia/juk/; revision=324972

svn path=/trunk/kdemultimedia/juk/; revision=317626

svn path=/trunk/kdemultimedia/juk/; revision=317624

svn path=/trunk/kdemultimedia/juk/; revision=317484

svn path=/trunk/kdemultimedia/juk/; revision=303788

but include the full path in the tooltip and by default sort by the full path.

However this does KMail-style "click twice on the header to change the sort
mode" and toggles between sorting on the full path and the file name.

CCMAIL:79118-done@bugs.kde.org

svn path=/trunk/kdemultimedia/juk/; revision=303244

CCMAIL:78665-done@bugs.kde.org

svn path=/trunk/kdemultimedia/juk/; revision=303184

over thier signal and slot code to normal method calls.  This code was pretty
ugly so this actually made things much more clear.

Also this required coming up with a more self contained MusicBrainz confirmation
process, so that's now been moved into MusicBrainzFileQuery.

Fixed a lot of includes along the way and removed a lot of unused cruft...

svn path=/trunk/kdemultimedia/juk/; revision=302745

svn path=/trunk/kdemultimedia/juk/; revision=302259

the QFileInfo from the tag altogether.

svn path=/trunk/kdemultimedia/juk/; revision=296013

everywhere else...

svn path=/trunk/kdemultimedia/juk/; revision=295979