2010/4/18 Maksim Orlovich <mo85@cornell.edu>:
>
>> Confirmed that GetVariable("$version") call on a flash plugin return
>> the version using the flash support of kmplayer plugin.
>> However, I can currently only get it by calling it after the plugin is
>> loaded, eg in body.onLoad.
>> So 'appendFlash = body.appendChild(flash)) && appendFlash.GetVariable'
>> will only work when starting a local event loop for the time the
>> plugin is up and running. Known to crash konqueror on unfortunate
>> redirects (*).
>
> Urgh. Did you check whether the actual youtube does this, or just the
> testcase? The exact sequence determines a lot on when we can actually
> create the part.

No, but using verbose logging, I don't see any GetVariable get's nor calls.

>>> Unfortunately, it's extremely
>>> tricky to fully implement with out-of-process plugins, especially since
>>> the presently used IPC system, D-Bus is inadequate for the task.
>>
>> Why? You mentioned that before and I only recall that the lack of
>> nested calls. But dbus supports nested calls just fine.
>
> Erm, that's not what Thiago told me :-). Anyway, I found our old
> discussion, and remembered a solution I had...

Pretty sure I've seen a nesting call, js calls plugin, plugin
evaluates some js code, depending on the result, the return value of
the initial call is determined.
Would be a major restriction not to have this feature. Maybe it's
unsupported, Thiago can tell I guess.

>> (*) That said, using the Qt eventloop for IPC is the source we cannot
>> block safely. Currently thinking about a way to block w/o running
>> processEvents (no OnlySocketNotifiers afaics), eg something with
>> qprocess waitForStarted(), waitForReadyRead() or so.
>
> ... which involves using a second thread to do the DBus connection, and
> blocking on the condition variable. I'll see if I can maybe make the class
> standalone, in case it'll be useful for you, too.

Could be indeed. Currently I'm thinking about blocking until I read
the dbus service name from the backend process on the stdout and then
a blocking play call.
If qdbus don't support nesting, this will certainly fail because it
starts asking for location.href on construction.

>> We also need a LiveConnect2Extension. As mentioned before, the string
>> based argument list/return value is too limited. We need at least a
>> way to pass proxies of js objects as arguments. On these proxies
>> get/put/call should be possible. Maybe simply use QVariant with a user
>> type for the proxy can work.
>
> Definitely. Could I ask you to review the API once I get there?

Sure :-).
Btw this particular case is really easy to solve using the current
nsplugin liveconnect object.

So in its 'get' function, prop being 'GetVariable':

NPObject *npobj;
NPVariant result;
NPError np_err = np_funcs.getvalue (npp,
                NPPVpluginScriptableNPObject, (void*)&npobj);
if (np_err == NPERR_NO_ERROR && npobj) {
    NPIdentifier identifier = nsGetStringIdentifier (prop);
    if (nsHasMethod (npp, npobj, identifier))
           //set return type to LiveConnectExtension::TypeFunction here
    nsReleaseObject (npobj);
}

and in its 'call' function the same but also calling nsIvoke on the
object. On the NPVariant return value, the 'type' field should be
NPVariantType_String and the string is in
value.stringValue.utf8characters, but be careful, it might not be null
terminated, so check the
stringValue.utf8characters for its length.
Return type being LiveConnectExtension::TypeString

Yep, not a fully npruntime module, but good enough to fix the plugin
loading thing in khtml (which of I have the feeling is a major task
too, afair the plugin widget creation was triggered by the rendering)

Koos

>
>
>