<div dir="ltr">On Thu, May 2, 2013 at 6:59 AM, Matěj Laitl <span dir="ltr"><<a href="mailto:matej@laitl.cz" target="_blank">matej@laitl.cz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 2. 5. 2013 Anmol Ahuja wrote:<br>
</div><div class="im">> Short description: My<br>
> proposal aims at revamping the Amarok scripting interface, and adding an<br>
> intuitive Script Creator graphical application allowing easy script<br>
</div>> creation by non-coders and coders alike. (...)<br>
<br>
Please update the short description to match the proposal as it develops.<br></blockquote><div><br></div><div style>Sorry, missed that.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
> Project Goals:<br>
<div class="im">><br>
> Part I : Setting up Automating Documentation<br>
><br>
> Setup Doxygen for automatically generating the Scripting API<br>
> Documentation wiki content from in-source documentation.<br>
<br>
</div>I don't think that wiki will keep to be the hosting for the generated<br>
documentation. Much rather <a href="http://api.kde.org/extragear-api/multimedia-apidocs/amarok/html/" target="_blank">http://api.kde.org/extragear-api/multimedia-apidocs/amarok/html/</a> will be the target.<br></blockquote>
<div><br></div><div style>Okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
> Bug 245647 <<a href="https://bugs.kde.org/show_bug.cgi?id=245647" target="_blank">https://bugs.kde.org/show_bug.cgi?id=245647</a>> -<br>
<div class="im">> Programmatic access to data objects in QtScript<br>
<br>
</div>Oh nice, this is actually the same idea I had with QueryMaker (simplified)<br>
interface.<br>
<br>
> Implementation Details<br>
> **<br>
<div class="im">> QObjects can easily be accessed in QtScript, an ECMAScript based language,<br>
> thanks to the Qt meta-object system. This can be achieved by passing them<br>
> to QScriptEngine::newQObject(), resulting in a QtScript accessible<br>
> QScriptValue with all of the QObject's public slots and signals, functions<br>
> with the Q_INVOKABLE macro, named child objects, and Q_PROPERTY parameters<br>
> (with SCRIPTABLE true) accessible in the script environment.<br>
</div>> **<br>
<div class="im">> In Amarok script, only selected methods are exposed to the QtScript<br>
> environment by creating QObject( and for prototypes, QScriptable ) -<br>
> derived wrappers for the classes to be accessed via Amarok script, to avoid<br>
> cluttering the scripting API and customizing behavior of Amarok classes to<br>
> be script friendly. This gives complete control over functionality made<br>
> available via the scripting API. These wrappers simply call the functions<br>
> of the actual class they link to, which do the real work. So, instead of<br>
> having to design Javascript equivalents of every class, only the wrapper<br>
> QObjects must be made and exported.<br>
</div>> **<br>
<div class="im">> I will be using the following QtScript classes in this GSoC project:<br>
</div>> **<br>
<div class="im">> -<br>
> QScriptable - For exposing Amarok classes like Collection,<br>
> CollectionLocation to the scripting environment. They will be exposed<br>
> using QScriptable and QObject derived classes registered as protoypes via<br>
> QScriptEngine::setDefaultPrototype(). The QScriptable derivation allows<br>
> accessing the scriptable environment's context from within the C++ code,<br>
> allowing access to the calling object and more.<br>
> -<br>
> QScriptEngine - Provides the environment for QtScript evaluation. Used<br>
> for setting custom protoypes of objects, setting global objects in the<br>
> scripting environment, etc.<br>
</div>> ***<br>
> -<br>
> Other basic classes, like:<br>
<div class="im">> -<br>
> QScriptContext for Javascript to C++ interaction, like accessing<br>
> function arguments, accessing the this pointer, etc.<br>
> -<br>
> QScriptValue : for translating objects back and forth between<br>
> QtScript and Qt/ C++.<br>
</div>> **<br>
<div class="im">> Qt Script uses garbage collection to reclaim memory used by script objects<br>
> when they are no longer needed, with this need being determined on the<br>
> basis of the ownership parameter passed as the second argument to<br>
> QScriptEngine::newQObject():<br>
><br>
> 1. Qt Ownership (default) - QObject owned by the C++ code, not the script<br>
> engine. That is, it managed according to Qt's object ownership.<br>
><br>
> 2. Script ownership - Script engine fully owns the QObject, deleting it<br>
> when there are no references to it in the script code.<br>
><br>
> 3. Auto-Ownership - Behaves like Script ownership when no parent, Qt<br>
> Ownership otherwise.<br>
<br>
</div>Very, very nice (the whole section above). Although I'm not a QtScript expert,<br>
this clearly shows that you have a very good understanding of how it works.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Here are class diagrams for some of the classes I plan on implementing, as<br>
> detailed in the project goals:<br>
><br>
> 1. Collection Management and Manipulation<br>
</div>> (...)<br>
> **<br>
<div class="im">> The QueryMaker will be exposed in a simplified form via the QueryFilter<br>
> class, which will use Collections::addTextualFilter and addDateFilter to<br>
> allow the CollectionBrowser search widget like queries. For example:<br>
><br>
> title:"carry" AND artist:"Fun."<br>
<br>
</div>Well, I think you'll need the code to "decode" the query and I think you can<br>
just reuse the same exact code used in Collection Browser. (perhaps moving it<br>
to some shared place)<br>
<br>
Otherwise nice.<br></blockquote><div><br></div><div style>ExpressionParser::parse, it's called in the Collections::addTextualFilter itself, so I don't have to separately parse it myself.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
> 2. AmarokScript::EngineController<br>
<br>
I'd prefix the new methods relating to track with "current", e.g.<br>
currentTrackLength() so that it is clearer.<br></blockquote><div><br></div><div style>Okay.</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In summary a very good proposal, Anmol! It is clearly visible that you've put<br>
a lot of work into it and I think it pays off. :-)<br></blockquote><div><br></div><div style>It's all thanks to your extensive reviews :)<br>I'll get make the final changes and update it on Melange by tomorrow.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Matěj<br></font></span></blockquote><div><br></div><div style>Thanks again :)</div><div style><br></div><div style>---</div><div style>Anmol </div></div><br></div></div>