us to use QScriptEngines from other sources (such as QML) we need
to change the code so that we don't have a custom QScriptEngine
subclass - only one codebase can do that at a time. The scriptenv
is now a normal QObject and contains a QScriptEngine instead of
inheriting from it.
svn path=/trunk/KDE/kdebase/runtime/; revision=1094259
* register the metatype by name with Qt so it can find it; this allows DataEngine::query() to work properly
svn path=/trunk/KDE/kdebase/runtime/; revision=1077821
* discovered QByteArrays were completely opaque to the runtime, obviously not good seeing how many things use them. fortunately, Qt has bindings for them ... in the examples! so just pulled those over (license compatible, thankfully) and now that works
* implement the remaining security hooks so it knows the difference between different kinds of urls
* export KIO::Job into the runtime; i really wish we could have had more time to do something more elegant than just pushing the object wholesale into the runtime as it exposes a LOT of API, but this works, should be safe (security wise) and as we are in feature freeze there's really nothing better that can be done to replace it at this point in time
* move some of the utility bindings (i18n, DataEngine) into simplebindings/ for consistency
* break out the qvariant stuff that is used outside of the DataEngine bindings for clarity
* brea out a bunch of the bookkeeping setup stuff from simplejavascriptapplet.cpp (it was getting messy) and put it into a separate .cpp file
svn path=/trunk/KDE/kdebase/runtime/; revision=1063070
