GitLab

This patch fixes the segmentation fault crash caused by clicking on an
empty area in the cover manager.

Thanks to Arjun Ak for the bugfix (you've been marked as the author),
and André Marcelo Alvarenga for reporting the bug

REVIEW: 114635
BUG: 326710

Changes:
* single quote chars
* casted floats to qBound
* KUrl instead of QUrl
* removed empty spaces
* added newline at eof

REVIEW: 114217

Thanks to Eric Newberry (from Google Code-In) for running the heavy
lifting on this.

I made some other corrections since we're touching all the source
anyways (e.g. fixing my email addresses), fixing the encoding of Richard
Lärkäng's name, and I've also chosen to avoid the fancy box-shaped
comments so that there's no issue with trailing spaces/tabs.

REVIEW:114216

BUG: 326543

We show a simple notification if the user starts up JuK and it is set to
dock in the systray on startup (as otherwise the user may wonder why it
didn't open up). Although a "Do not show again" checkbox is not possible
with KNotification, it is possible to remove this additional
notification by going to "Application and System Notifications" in
System Settings to manage "Juk music player" application notifications.

We do *not* show a notification if a session is being restored to avoid
noise, however JuK will show the main window if the user tries to start
it up again after it's already running, so this should be OK.

Thanks to Shubham Chaudhary for the bugfix (you're been marked as the
patch author), and Michael for reporting the bug.

This bugfix adds new strings so it cannot be backported. It will show up
first in KDE SC 4.12.

BUG:316832
FIXED-IN:4.12
GUI:

Conflicts:
	main.cpp

PlayerManager will always emit a track changed signal, which means the
Scrobbler will always have to receive it even if we're not scrobbling
(my last change to avoid making network requests when not using last.fm
broke this, it seems).

Instead move the Scrobbler into the base application class where we can
track whether scrobbling is enabled or not, and Do the Right Thing. I
don't have a last.fm account so although this should still work (I
think), I can't verify. I have verified that we at least don't crash
anymore. Martin, can you double-check when you get a chance?

FIXED-IN:4.11.2
BUG:323703

This rarely happens since taglib will simply create an ID3 tag if one
didn't exist before... but taglib can't do this if it can't find the
file, which now seems to occur for files with a non-UTF8 filename
encoding.

You see this as a 'Couldn't resolve the mime type of <<foo>> -- this
shouldn't happen' message on the console. In this situation JuK is able
to resolve the file to an appropriate TagLib::File subclass, but the
TagLib object is in an invalid state.

CoverInfo wasn't checking for this (it was assuming any TagLib::File*
that it was given was valid).

I took a look through the reported JuK crasher bugs and didn't see
anything relevant.

I'm not sure whether this will end up in the KDE SC 4.11 or 4.11.1.

Since Cache no longer also acts as a collection of FileHandles there's
no need for FileHandleHash. Get rid of it, replace its one use by the
equivalent data structure within CollectionList.

This is another attempt to work around JuK <=> Plasma DBus deadlocks,
but making some of the DBus methods that Plasma would call into via the
MPRIS2 interface be async.