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