[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: QML-using app developers: use private.* imports
From: Aleix Pol <aleixpol () kde ! org>
Date: 2013-09-26 0:23:31
Message-ID: CACcA1Rp8fSmTyaXxtsnWynuXMhBP5W=kino__GYoG5N87-_UeQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Sep 25, 2013 at 3:51 PM, Sebastian K=C3=BCgler <sebas@kde.org> wrot=
e:
> 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 impor=
ts
> 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 a=
nd
> 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 b=
y
> 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
[Attachment #5 (text/html)]
<div dir="ltr">On Wed, Sep 25, 2013 at 3:51 PM, Sebastian Kügler <span \
dir="ltr"><<a href="mailto:sebas@kde.org" \
target="_blank">sebas@kde.org</a>></span> wrote:<br><div class="gmail_extra"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all,<br>
<br>
In Plasma, we've been looking into privatizing parts of the QML API we offer.<br>
With Qt5, we rely less on setContextProperty() and friends, and use imports<br>
more. That's a technical necessity that makes one problem more evident: \
It's<br> unclear what QML-facing API is reliable and stable, and what is private \
and<br> internal API. As there are no restrictions (right now) which imports may \
be<br> loaded by a piece of QML, we need another solution.<br>
<br>
Our approach hooks into the import loader, and will disallow loading certain<br>
plugins. This is not implemented yet, but we would like to prepare this by<br>
having streamlined import names, which can eventually be enforced.<br>
<br>
We would like to introduce this as good practice for not-just-plasma, so it<br>
would be nice if applications could use the same patterns: Only install into<br>
org.kde.* what you consider stable API. For internal imports, use private.*,<br>
for example private.org.kde.yourapplication.module.<br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888">--<br>
sebas<br>
<br>
<a href="http://www.kde.org" target="_blank">http://www.kde.org</a> | <a \
href="http://vizZzion.org" target="_blank">http://vizZzion.org</a> | GPG Key ID: 9119 \
0EF9<br> </font></span></blockquote></div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Either way, I have no \
idea of what we're talking about here. :D</div><div \
class="gmail_extra"><br></div><div class="gmail_extra">Cheers!</div><div \
class="gmail_extra">
Aleix</div></div>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic