i18n and KFileMetaData

[Matthieu Gallien]

Le 13 mai 2017 14:18, "David Faure" <faure at kde.org> a écrit :

On lundi 8 mai 2017 13:09:03 CEST Luigi Toscano wrote:
> Matthieu Gallien ha scritto:
> > Hello,
> >
> > Currently KFileMetaData is a tier 2 framework even when you remove all
> > optional dependencies on other frameworks due to a dependency on ki18n.
> >
> > I would like to know if people think it would be possible to transition
it
> > to depend on Qt for i18n so as to lower its tier ?
> >
> > Currently, ki18n is used to provide localized name for properties on
file.
> >
> > I would like to get more people to use it outside core KDE software. For
> > example, people could use it for music players built on top of Qt. I
> > believe lowering the tier can help this.
> >
> > What do you think ?
>
> Even if the usage of KI18n is limited and it could be replaced with the Qt
> native system (basic strings, no arguments), I'm not sure that you can
> officially lower the tier with optional dependencies. Others may remember
> better of course.

Let's not debate semantics of tiers. What really matters is that if
KFileMetaData has optional dependencies on other frameworks, then chances
are
quite high that Linux (and other) distributions will provide binary packages
of KFileMetaData *with* these dependencies compiled in. So in practice your
music player will depend on these optional dependencies anyhow, so "tier2"
is
more correct than "tier1".


My music player is using ki18n and I am happy with it. I am still hoping
KFileMetaData could be useful by itself not necessarily linked to other
frameworks. Improving the documentation would be the next task to do.


It only makes a difference for people who compile from sources, they can
choose to skip the optional deps and therefore have less things to compile.
This is very valuable of course, and I'm all for it (it lowers the bar for
contributions).


This is my main motivation.


--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170517/c93e7480/attachment.html>