On Mon, Jan 14, 2013 at 4:33 PM, Luca Beltrame <span dir="ltr"><<a href="mailto:lbeltrame@kde.org" target="_blank">lbeltrame@kde.org</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">

In data lunedì 14 gennaio 2013 16:30:15, Aaron J. Seigo ha scritto:<br>
<div class="im"><br>
> the real fix, however, is not to do the UI in python. use QML.<br>
<br>
</div>Speaking of that, how does Plasma (or the workspace in general) fit when using<br>
QML, according to these 3 definitions (taken from the PyQt docs):<br>
<br>
1. Pure applications that are written entirely in QML and can be run using the<br>
qmlviewer tool provided with Qt. PyQt4 fully supports this type of<br>
application.<br>
<br>
2. QML allows QObject instances to be used in QML applications. QML code is<br>
able to call an object’s slots and has read and write access to the object’s<br>
properties. QML code can also respond to changes to the value of a property.<br>
PyQt4 fully supports the use objects created in Python in this way. T<br>
<br>
3. QML also allows QObject sub-classes to be used in QML applications so that<br>
new instances are created from QML. PyQt4 does not support this. The reason is<br>
that QML uses information generated at compile time (specifically it uses<br>
QObject::staticMetaObject) rather than information created dynamically at run<br>
time (i.e. QObject::metaObject()). This approach is fine for a static language<br>
like C++ but causes problems for languages such as Python that allow types to<br>
created dynamically.<br>
<br>
This may be important for users of bindings.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Luca Beltrame - KDE Forums team<br>
KDE Science supporter<br>
GPG key ID: 6E1A4E79</font></span><br>_______________________________________________<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>
<br></blockquote><div> </div></div>I think I already discussed this with someone in Randa, from my point of view, the best abstraction is at the "import" level.<div><br></div><div>If you want C++ in Plasma, you make a declarative plugin that exposes some modules.</div>

<div>With Python (or Haskell or Ruby) the same should happen.</div><div><br></div><div>This would mean that as long as it's possible to use QtCore in those languages, we can start integrating them.</div><div><br></div>

<div>If we can leverage the bindings to Qt, we reduce complexity and we get a lot of stuff for free that will be also more re-usable in other applications.</div><div><br></div><div>...no? :)</div><div>Aleix</div>