QML-using app developers: use private.* imports

Mark markg85 at gmail.com
Wed Sep 25 15:51:41 UTC 2013


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
>
> Doesn't your naming proposal completely ruin the org.kde.* stuff? Up until
now i could fairly safely assume that all QML KDE imports where hidden
under org.kde.* but that isn't the case anymore if you introduce
private.org.kde.*

It looks like you miss a part in the url.. I would say something like this:
org.kde.public.* = public imports
org.kde.private.* = private imports

But that would require changing all existing components to reflect this
idea..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130925/86a9bc22/attachment.html>


More information about the Plasma-devel mailing list