GitLab

Now that sorting is enabled, it turned out that the sort really was
broken for everybody (sorry!). The old Qt 3 and 4 "sort by subclassing
the list item" feature wasn't actually ported into the Qt 5
compatibilility list view. So although we were defining the compare
function, nothing was actually using it.

Things seemed to work fine on my local system but I suspect that's
because I had playlists from KDE 4 times that I copied over which would
have already sorted the special playlists to the beginning.

Since the old method doesn't work I've just added a hidden sort key
column for now. The "proper solution" is probably to use a
QSortFilterProxyModel but that will be some time away.

CHANGELOG:Restore proper sorting of the list of playlists.
BUG:402398
FIXED-IN:18.12.1

That is, so that special playlists hopefully sort to the top. Although
the sorting of special playlists (Collection List, Play Queue, etc.) has
worked for me since the port to KF5, I have a good report that it
doesn't for others.

The code itself appears correct but reviewing the Qt documentation
indicates that QTreeWidget (which is one of the base classes for the
list of playlists) doesn't sort by default.

If QTreeWidget doesn't sort, then the comparison function might not be
getting called at all, which would make it accident that it seems to
work for me.

CCBUG:402398

Brings in latest bugfixes.

The "Show Columns" menu would previously have a checkbox entered for
every possible column for the playlist shown by default at JuK startup,
even though most columns were not visible.

This turned out to be because the class that reads the column
configuration (Playlist::SharedSettings) was not being used to generate
the Show Columns menu options. Instead the Playlist's own (defaulted)
values were used.

At this point in execution we can't force SharedSettings->apply() to run
because the Playlist is not fully setup. Instead we expose the config
values and use those to generate the menu.

Conflicts:
	CMakeLists.txt

This mitigates a potential data-loss situation that might happen when
adding new music items:

  Juk starts processing the new items in addFiles,
  Results in a new CollectionListItem being created,
  The resultant PlaylistItem superclass calls setFlags,
  This causes Qt to send a *data* changed signal from the QTreeWidget
    holding all the playlist items, saying that a *different*
    QTreeWidgetItem / PlaylistItem has been changed.
  This signal is normally only possible because of user interaction with
    the inline editor. As a result JuK assumes the signal is a user
    request to edit the track's tag, and does so. I have seen this
    cause existing files to take on the same tag values as one of the
    incoming new tracks.

Although in theory a user could immediately select the "Undo" command to
fix this, that's not a very good workaround. Since we have a separate
tag editor already, we'll just use that instead until we can figure out
a way to ensure that dataChanged signals are sent only when the data
itself has changed (not just flags caused by unrelated items being
created).

CHANGELOG: Prevent opening new items from inadvertently editing track metadata on existing items.
FIXED-IN:18.12.1

Includes template-template parameter usage in playlist.h's createItems
until all usages of QList gone.

Large music libraries can cause dozens/hundreds or even more of threads
to be created at once. But all we really need is to do the loading off
of the GUI thread, and the I/O will be the bottleneck no matter how many
threads we use. So use Qt Concurrent to manage a threadpool instead,
which also simplifies the code somewhat.

I also fixed the broken global status updating when using threaded
loader while refactoring to support this.

I ran into all the problems one might expect from adding threading to an
old codebase but this variant seems pretty stable.

The benefit is that the heavy I/O with large music libraries is now off
of the GUI thread. So even though it will still take awhile to load all
music until I fix the bug(s) with using cached tags, at least the
application itself will be responsive while it loads audio.

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"

A prior code cleanup started trying to open the default KWallet
automatically, skipping the existing check for whether scrobbling is
enabled. Instead of reverting, add the check to the wallet opening code,
which already has to handle the possibility of failure.

Based on patch provided by tanjoodo, but simplified to create the
missing QNetworkAccessManager unilaterally.

This avoids a crash in the scrobbler when scrobbling is attempted with
an active session but no network manager (such as when the configured
internet connection is lost).

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

GUI: This fixes things like the warning icons in the file deletion
dialog, file renamer, menu icons (such as Create Playlist from Selected
Items), and the "Jump to Playing Track" button on the status bar.

The track position slider remains unfixed.

This lets Hi-DPI displays to show cover art (when clicking the cover in
the "Now Playing" bar) at its native resolution even when using screen
scaling.

This is probably suboptimal for smaller covers but most embedded cover
art I find in the recent few years is already more than large enough to
show up fine this way.

CHANGELOG: Show embedded music cover art at native display resolution.

Conflicts:
	CMakeLists.txt

As submitted by Guo Yunhe <i@guoyunhe.me> on kde-multimedia.

In my testing this only applies with QT_AUTO_SCREEN_SCALE_FACTOR
environment variable enabled, but does indeed allow for many (not all)
pixmaps to automatically load high-res versions (such as from
KIconLoader).

I consider this a bugfix and the support is non-invasive, so applying to
18.12 and will merge to master separately.

Note that the cover art and slider art is still suboptimal.

Conflicts:
	playermanager.cpp

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

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.