On Fri, Jan 18, 2013 at 10:26 AM, Marco Martin <span dir="ltr"><<a href="mailto:notmart@gmail.com" target="_blank">notmart@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Friday 18 January 2013, Aleix Pol wrote:<br>
<br>
> If we can leverage the bindings to Qt, we reduce complexity and we get a<br>
> lot of stuff for free that will be also more re-usable in other<br>
> applications.<br>
><br>
> ...no? :)<br>
<br>
</div>no :p<br>
<br>
as i already explainer there back in randa, there are tons of occasions and<br>
use cases where doing a new import makes totally sense.<br>
<br>
but again, this automatically means guaranteeing good and stable api, (and to<br>
be a function that maes sense at all outside one single app/plasmoid) is the<br>
same reason you don't export a public library for all the c++ code you<br>
write...<br>
...or you do? :)<br>
<br>
<br>
Cheers,<br>
Marco Martin<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</div></div></blockquote></div><br><div>Is it really a matter of enforcing API stability? Whenever you introduce some code there will be some quality to maintain. For example with data engines, there's also strings that define how it's going to work.</div>

<div><br></div><div>Also it doesn't always mean that you have to put every code available to all modules. I can imagine bundling python code within a plasma package and do something like addImportsPath("plasmapackage://imports") for every package.</div>

<div><br></div><div>Aleix</div>