GitLab

JSON doesn't really support comments, making our flatpak file
invalid.

https://bugzilla.gnome.org/show_bug.cgi?id=785697

This function can be used to remove common articles when sorting, so
avoid open-coding that in the SPARQL queries. This also brings the
benefit that queries turn a lot less complex, so there's less chances
to hit parser limits.

https://bugzilla.gnome.org/show_bug.cgi?id=783466

These two need to match to correctly show up in gnome-software.

The current AlbumArtCache implementation does not keep track of the
number of concurrent lookups that are being executed.

When dealing with a small number of items this is acceptable, but once
the number of music items grow, this poses a big problem. In fact, the
biggest bottleneck for when Music is loading is caused by the thousands
of lookups finishing almost at the same time and overloading GTK+
machinery.

Fix that by introducing a limit to the number of concurrent lookups
being executed. When the limit is hit, the lookups are queued and
executed once a new lookup slot is available.

Notice that downloads are not considered lookups, and file loading is
done in parallel to cover fetching.

No code changes needed. API remains compatible with the current usage
in gnome-music.

See https://bugzilla.gnome.org/show_bug.cgi?id=781326

https://bugzilla.gnome.org/show_bug.cgi?id=781754

https://bugzilla.gnome.org/show_bug.cgi?id=777346

The artist field was mistakenly retrieving the album title.

https://bugzilla.gnome.org/show_bug.cgi?id=781684

(cherry picked from commit 870891c0)

All pre-configurations that must be set before starting gnome-music were
grouped in proper functions so it is now easier to read, understand and
maintain. It also follows PEP-8 when possible.

https://bugzilla.gnome.org/show_bug.cgi?id=774500

Old progress scale value was not updating causing minor stuttering.
Update its value when a seek is finished.

https://bugzilla.gnome.org/show_bug.cgi?id=776668

This reverts commit 6c88265f.

This reverts commit fe2c057d.

This reverts commit 26cbbe19.

This reverts commit 400fbe9e.

Music works with lower requirements, but there are some features that
aren't working right without 0.3.3 and plugins 0.3.4. Sadly it is not
currently possible to force the plugins version, so do the best we can.

Workaround for the issue where get_tags returns None. According to the
API this shouldn't happen, but reports indicate otherwise resulting in
crashes.

https://bugzilla.gnome.org/show_bug.cgi?id=780980

So it can be used by devs to build against in GNOME Builder.

https://bugzilla.gnome.org/show_bug.cgi?id=779905

Up until now we were using gnome-music.desktop as name for the desktop
file.

However this is discouraged since it's not using a unique id similar to
dbus addresses.
This also bring the problem that to build with flatpak the desktop file
has to match the dbus address.

So simply rename the desktop file to org.gnome.Music.org

https://bugzilla.gnome.org/show_bug.cgi?id=779905

During population of the dialog's list, check if the item id is equal to
the id of the playlist that is going to be deleted. If true, then do not
display the item.

https://bugzilla.gnome.org/show_bug.cgi?id=780523