diff options
author | Kent Hansen <khansen@trolltech.com> | 2009-07-27 17:42:26 (GMT) |
---|---|---|
committer | Kent Hansen <khansen@trolltech.com> | 2009-07-27 18:01:19 (GMT) |
commit | 8923339fa086cbf6adc404fb18dcda6c1206985d (patch) | |
tree | 13ad42fc95c63e9f49a971a42fab7ddb1c6af61c /qmake | |
parent | 117802b5ca71478d01bb79f88aa3596729b0a590 (diff) | |
download | Qt-8923339fa086cbf6adc404fb18dcda6c1206985d.zip Qt-8923339fa086cbf6adc404fb18dcda6c1206985d.tar.gz Qt-8923339fa086cbf6adc404fb18dcda6c1206985d.tar.bz2 |
make QScriptEngine::setGlobalObject() work to some extent
JSC requires that the global object is actually a
JSGlobalObject instance, whereas QScriptEngine::setGlobalObject()
allows any object to be set as the global object. The way we
solve this is by proxying from an internal global object to the
custom (user-set) object.
We need to take care that the internal global object is never
actually exposed through our API; a brilliantly named helper
function, toUsableValue(), makes that happen.
Evaluating "var a = 10" with a custom global object doesn't work
yet; the variable always ends up in the internal Global Object.
For variable assignments, JSC appears to bypass the normal
JSObject::put() and instead use
JSGlobalObject::copyGlobals{From,To}(), which means I can't
intercept and proxy the assignments.
This commit enough to get the Context2D example working. There's
another bug with iteration of the built-in Global Object's
properties (non-enumerable properties are always skipped by the
JSC C++ API, whereas with QScriptValueIterator they should not
be), but that's a totally separate issue.
Diffstat (limited to 'qmake')
0 files changed, 0 insertions, 0 deletions