<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">Le 18 mai 2017 02:11, "Aleix Pol" <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> a écrit :<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Wed, May 17, 2017 at 9:57 PM, Matthieu Gallien<br>
<<a href="mailto:gallien.matthieu@gmail.com">gallien.matthieu@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> As a follow up of a discussion on android list, I would like to gather some<br>
> comments or point of views about the following dilemma.<br>
> Currently, the mandatory parts of KFileMetaData compile for Android using API<br>
> level 21 (Android 5.0). The class UserMetaData is relying on extended<br>
> attributes supported ony starting with API level 21.<br>
> My own phone is Android 4.4 (API level 20). I am wondering if making the class<br>
> UserMetaData be optional (currently part of the ABI) is a good idea. I could<br>
> ensure it is only optional on Android as a way to not break the ABI.<br>
><br>
> According to Google (<a href="https://developer.android.com/about/dashboards/" rel="noreferrer" target="_blank">https://developer.android.<wbr>com/about/dashboards/</a><br>
> index.html) its still 18.8 % of the phones.<br>
><br>
> Any advice, comments, ... ?<br>
><br>
> Thanks in advance<br>
><br>
> Best regards<br>
<br>
</div>Hi Matthieu,<br>
At the moment we don't have a global KDE policy WRT which Android API<br>
level our frameworks and applications are going to require. I'd say<br>
that it's fine that an application can require N because a framework<br>
requires N.<br>
<br>
The fact that you have a phone that doesn't support the framework you<br>
want to use is unfortunate, although it seems a bit odd to leave a<br>
whole class out because of that. I'd say that it's a positive feature<br>
that if an application is ported to Android, the same features are<br>
still available.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Yes, I agree in general. In this case, I am not sure. For example, the ratings will not be interoperable on Windows if they are stored in the current way (an extended attribute called user.baloo.rating).</div><div dir="auto">In a sense, we pretend it is working even though a rating made in Windows explorer will not be read by the library. The opposite is also not working.</div><div dir="auto"><br></div><div dir="auto">I should maybe just improve the documentation with respect to that.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A compromise could be to introduce a dummy implementation of the class<br>
in case the feature we require currently isn't available.<br>
<br>
HTH,<br>
Aleix<br>
</blockquote></div><br></div></div></div>