QML-using app developers: use private.* imports

[Aleix Pol]

On Wed, Sep 25, 2013 at 3:51 PM, Sebastian Kügler <sebas at kde.org> wrote:

> Hey all,
>
> In Plasma, we've been looking into privatizing parts of the QML API we
> offer.
> With Qt5, we rely less on setContextProperty() and friends, and use imports
> more. That's a technical necessity that makes one problem more evident:
> It's
> unclear what QML-facing API is reliable and stable, and what is private and
> internal API. As there are no restrictions (right now) which imports may be
> loaded by a piece of QML, we need another solution.
>
> Our approach hooks into the import loader, and will disallow loading
> certain
> plugins. This is not implemented yet, but we would like to prepare this by
> having streamlined import names, which can eventually be enforced.
>
> We would like to introduce this as good practice for not-just-plasma, so it
> would be nice if applications could use the same patterns: Only install
> into
> org.kde.* what you consider stable API. For internal imports, use
> private.*,
> for example private.org.kde.yourapplication.module.
>
> Thanks,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>

Reducing API to maintain is a good thing, at least for complexity sake. But
of course there will be always the case where somebody needs (part of) the
private API.

The question would be then, why is it that there's some API that's only
needed for internal usage? If it's needed internally, it will be most
likely needed externally, at some point. The fact that you decide to label
it as private makes frustrated developers.

Either way, I have no idea of what we're talking about here. :D

Cheers!
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130926/d4d7f4f4/attachment.htm>