Use Amber.Mpris instead of org.nemomobile.mpris on newer SailfishOS releases

[smokku]

Amber.Mpris is offered since SailfishOS 4.4.0.

Closes #98

[Olf0]

@smokku, thank you very much for this contribution.

Currently, my first comment addressing your other contribution (PR #33) is also applicable here. I am sorry for the delay.

[Olf0]

@smokku, can you please consider implementing a switch as dcaliste did for resolving PR #33 (if technically feasible) or alternatively at least look up exactly which SailfishOS releases …

1. introduced Amber.Mpris
2. omitted org.nemomobile.mpris

[smokku]

@smokku, can you please consider implementing

I tend to work in bursts, jumping from subject to subject.
I got bored with SailfishOS and I'm doing different stuff now.
I may get back and do some more stuff for Sailfish though…

[Olf0]

I tend to work in bursts, jumping from subject to subject.

Take your time, it is all spare time activity and should primarily be fun.

[Thaodan]

I wonder if it is worth the effort to support Sailfish OS pre 4.0 when it adds so much overhead.
It doesn't look like it can be done easily (from a quick read).

[Olf0]

1. Technically

   Well, the old, extant code is in this git repository, the new code is here in this PR, hence IMO it just takes a flag and a ifdef / ifndef construct to compile either code conditionally. The flag can be set based on sailfish-version in the spec-file. Examples for this construct are the SailfishOS:Chum GUI application and many of Slava Monich's apps, e.g. CodeReader.

   The exact SailfishOS release which brought this breaking change has to be determined any way in order to let FlowPlayer only install on appropriate SailfishOS releases. All release notes, one of which should document this change, are referenced here: Fix WebDAV + Thumbnail + Open + Share + port.text + another fix filecase#60 (comment)

   All in all this should be not be hard to implement, just a bit tedious to adapt this well known construct to FlowPlayer and to reference the original change in SailfishOS in Jolla's release notes or changelogs.

2. Organisationally

   Jolla is free to regularly (with almost every minor SailfishOS release) break many third party SailfishOS apps (and sometimes also their own) with their disruptive changes (i.e. non backward compatible ones) and to destroy the remainder (or rather remnants) of the SailfishOS app ecosystem thereby. But I am tired of permanently adapting apps to these disruptive changes, although I have not ceased to maintain them completely as so many other developers already did; still I would rather enhance these apps instead of being kept busy by fixing the breakages Jolla causes.

   The biggest and worst fact in this context is that the most central of all software components to create apps nicely provides backward compatibility for all its minor releases: Qt But Jolla refuses to update exactly this core component and still deploys Qt 5.6, which was released 1. March 2016 and does not receive security updates any longer since 1. March 2019. Instead of updating Qt to 5.15, which should cause only minimal compatibility issues, Jolla loves to change many other, little things in SailfishOS in a disruptive manner, often without any necessity for disruptiveness or almost ever without announcing such breaking changes. Consequently SailfishOS has no future (since 2019) and I will not actively support Jolla's crazy course by fixing the breakages they cause, unless they switch to a Qt release which is still maintained (i.e. either 5.15 or 6.x); still I do review and integrate PRs which address any of these breakages in a backward compatible manner.

   The codebase of FlowPlayer currently supports every SailfishOS release since at least 2.0.0 (maybe also 1.1.9), I see no reason to destroy this feat. Do you?

[Thaodan]

First of all I don't understand the need for such a wall of text on such a simple question: Is it worth to keep compatibility with long unsupported Sailfish OS versions to detriment of the maintainability of the application. For me the answer is a clear no unless we talk about most recent minor versions. With such a reply as yours you keep contributors of any projects you are involved in off, most of the comment is unrelated to my comment and diverting from the current topic (especially since I commented here as just another community member as this is unaffiliated with Jolla).

[Olf0]

You received a clear answer to your question and additionally a detailed description of one way how to proceed: Feel free to pose a PR; I also promised that I will handle it.

Just read, don't rant.

[Olf0]

I do no comprehend what you are trying to achieve with your personal attacks; obviously my comment hit a nerve.

Unfortunately you contribute nothing constructive in all your postings here, only try to command people outside of Jolla (here: me, again) what to do, as so often.
I hope you had your fun. 😉

[Olf0]

From #34 (comment):

@smokku, can you please consider implementing a switch as dcaliste did for resolving PR #33 (if technically feasible) or alternatively at least look up exactly which SailfishOS releases …

1. introduced Amber.Mpris

2. omitted org.nemomobile.mpris

1. is SailfishOS 4.4.0.58, see https://forum.sailfishos.org/t/changelog-vanha-rauma-4-4-0/10655
   _{Edit: I updated the initial posting in this thread accordingly.}

2. org.nemomobile.mpris is not mentioned in the changelogs of SailfishOS 4.4.0.58, 4.5.0.16 and 4.6.0.11, hence it may be still valid and functional [as of SailfishOS 4.6.0]:
   This would need testing or a negative effect (missing functionality etc.) with FlowPlayer on SailfishOS ≥ 4.4.0 to be documented.
   See this FSO posting WRT the RPM packages mpris-qt5 and mpris-qt5-qml-plugin (the latter package depends on the former).

   Due to the line Requires: qml(org.nemomobile.mpris) in FlowPlayer's (as of v0.3.5-release3) spec file, MPRIS should be working fine at least up to and including SailfishOS 4.6.0.