GitLab

I did this because I got annoyed about my own log messages about
inhibiting/uninhibiting power management.

This ultimately was because Phonon forces a stop and then restart
sequence whenever forcibly changing the current media source, as we were
doing to switch tracks.

Phonon provides a way to queue up additional tracks to play when
playback is about to end which keeps itself in a playing state. I use
this method, which may also theoretically make gapless playback work.

This makes the playback handler that accepts a FileHandle on purpose a
bit easier to think through.

The only reason we couldn't perform setup on construction was because of
some U/I setup code that couldn't happen when the player manager is
normally constructed.

But the U/I setup is simple enough to move to JuK, so do so. Now the
rest of PlayerManager is that much simpler.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

- make sure the XML with the album is the one we expect (<lfm> as
  root element)
- if the status is not "ok", inform whether the album was not found,
  or there was another error
- handle when the album has no cover

In all the above situations, WebImageFetcher does not attempt to start
a StoredTransferJob for an empty URL.

The dialog with the cover result is destroyed only if the user accepts
the result, showing no results for further searches in case the cover
dialog is cancelled.

Instead, make sure to destroy the cover dialog also in case the user
cancels it.

Summary:
Instead of pointing to the homepage of the wiki,
set the link to the actual page of the lyrics
which are being shown.

BUG: 332664
FIXED-IN: 18.12.0

Test Plan:
The link to the LyricsWiki points to the actual page.
Nothing changes when the lyrics are not found.

Reviewers: mpyne

Reviewed By: mpyne

Differential Revision: https://phabricator.kde.org/D15303

Summary:
With this change the time is correctly updated also when using
the VLC backend.
It worked for some reason with phonon-gstreamer, but it looks like
it's just by accident. In fact, according the documentation, the default
value of the property is 0:
https://api.kde.org/phonon/html/classPhonon_1_1MediaObject.html#ae0f0ab91c97a1f3495ed9467048bb81a

The choosen value (100) should allow for a fluid scrolling of the
progress element, without having a too small resolution, and
it seems to match the resolution of the gstreamer backend anyway.

BUG: 389907

Test Plan:
The time is updated on both the progress bar and the status bar with
both VLC and GStreamer Phonon backends.

Reviewers: mpyne

Reviewed By: mpyne

Differential Revision: https://phabricator.kde.org/D15222

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

This was a KDE 4 JuK feature that had been left disabled in the port to
Plasma 5/KF5. I finished the implementation here in response to a user
request.

Given the code changes it's technically best described as a new feature
(even if it used to work in KDE 4) so it probably won't show up until
the next release of KDE Applications, though it should be safe to
backport for interested distributions.

GUI:
BUG:395948
FIXED-IN:18.08

Adjust the way we randomly pick the next track to play to remove a
potential bias towards tracks that are earlier in the list.

On GNU the bias is extremely slight since RAND_MAX is so high, but it's
not that much harder to do it right.

I missed 3 commits due to the timing of the creation of
Applications/18.04 branch versus when I committed. :(

Thanks to tosky for pointing that out to me.  But that means these 3
commits won't be available until 18.04.1.

KStatusNotifierItem's 'maybeQuit' function is more than happy to call
qApp->quit directly even though the standard quit action is available to
be triggered and would do the right thing.

Qt documents you can use aboutToQuit to catch this case, and it does
seem to work.

JuK would fail to shutdown properly under Plasma 5 when the system tray
was disabled and you used the 'X' from the window manager title bar to
try to close JuK.  May have failed under other WMs or desktops as well,
I haven't tested that.

The shutdown code hasn't been reworked since KDE 3 times and for all I
know I introduced this bug with the setQuitOnLastWindowClosed setting in
main.cpp years ago and never realized.

But this way, any way you destroy the main application class (JuK), you
end up shutting down.  Continuing to use setQuitOnLastWindowClosed
appears to be necessary since Qt will remove the queued quit signal to
qApp once JuK is destructed and I don't trust running qApp->quit within
the JuK dtor itself.

Hopefully this fixes a crash-on-quit bug, but if not just reopen and
I'll figure it out somehow...

FIXED-IN:18.04
BUG:388663

It appears to be possible to configure JuK to start in docked mode even
if the system tray icon has been disabled by the user, which is quite
pointless.  Prevent this by forcing the window to be shown at startup if
the system tray icon is not turned on.