GitLab

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.

This helps a little bit with JuK freezing Plasma due to DBus deadlocks
from synchronous calls being made between KStatusNotifierItem, its
Plasma notification area counterpart, and the MPRIS2 adapter and its
Plasma counterpart(s).

Proper fix is async everywhere as far as I can tell.

The effect is simulated by using deleteLater(). I have been unable to
reproduce any crash this way so hopefully whatever is mentioned in the
old comment does not apply to this new code.

In an attempt to get rid of processEvents() (related to several existing
crash bugs) I am trying to port the startup code towards more
async-friendly schemes.

There's no threading but we at least get back to the event loop much
more frequently while loading files.

Additionally I have added debug output with instrumentation to show how
long it takes to advance through each step of the startup (I think this
might be the first time anyone has understood JuK startup sequence in
years).

This leaves some essentially dead code with Cache (which no longer
acts as a container), which I will try to cleanup in later commits.

Kind of embarassing it took so long to track down why multiple
seemingly-random PlaylistBox::Items were selected.

This helps avoid the perception that a network request is being made
when it's actually still evaluating whether to send the request or not,
really helps with JuK debug spam.