GitLab

This fixes a bug that recently hit its 8 year anniversary. :(

The big issue was that there was no easy way to tell which keyboard
modifiers were set for the systray since Qt's event loop didn't actually
receive the keyboard events.

There's a separate function you can call, queryKeyboardModifiers, which
makes a specific query to the desktop, and works even if Qt event loop
didn't receive keyboard events. This fixes the bug here, and hopefully
for everyone else.

In fixing the bug I noticed that we can set out-of-bounds volumes due to
lack of checking, so I fixed that too.

BUG:250355
FIXED-IN:18.08.3

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:
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"

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.

Reviewers: mpyne

Reviewed By: mpyne

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

We already have a separate playPause action for this, both in the MPRIS2
DBus adaptor, and in PlayerManager.

This also fixes playback resuming when the computer is suspended (Plasma
sends the "Pause" command to each media player regardless of whether
it's playing, and JuK incorrectly treats that as a request to toggle
playback).

BUG:381271
FIXED-IN:18.04

Should allow JuK to start on Wayland.  Should also allow arguments to be
passed to JuK (which in theory supports loading files from command
line).

I ask for URLs to be passed (%U) instead of files (%F) to avoid
over-eager file managers or desktops trying to download music files to a
temp directory and then deleting them once JuK is done.

GUI:
BUG:391354
FIXED-IN:18.04

As nicely requested in bug 391308.

BUG:391308
FIXED-IN:18.04

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 helps declutter playlist.cpp and even makes it seem a bit easier to
read through, I think.

I also tried to fix a couple of outstanding bugs along the way, for
instance reordering columns should work now, although there's still a
lot of improvements that need to be made here.

This seems to prevent a gstreamer deadlock I sometimes get when trying
to quit, though it's only a guess as to whether this is the cause or
not.