Qt 4.7 WebPage is a widget??
-
[quote author="DavidGOrtega" date="1294248371"]In practice I use QWebPage in a server in Qt 4.5 to bring server side javascript with native code accesible throught wrappers, like node.js and others does.
Coming to Qt 4.7 everything breaks...[/quote]
Why not use QScript directly if it is just about using Javascript on server side?
-
viv.ojha are you repeating the same as Benjamin!!????
Benjamin, I have found much more faster using the engine directly than using QScriptEngine not only that but I using other modules, that are much more compatible with QWebPage than with QScriptEngine since QWebPage is DOM based and the scriptengine not, like the debug based enviroment that I have done.
I'm thinking in issolate the QWebPage in a executble accesed with the QProcess but I haven't found good points on it. That direction should solve aldso the Webkit memory leaks.
Can you point an example to me?
Anyway I can't undestand when documentation says "...widget-less enviroment..."
Thanks
-
[quote author="DavidGOrtega" date="1294390387"]
Benjamin, I have found much more faster using the engine directly than using QScriptEngine not only that but I using other modules, that are much more compatible with QWebPage than with QScriptEngine since QWebPage is DOM based and the scriptengine not, like the debug based enviroment that I have done.
[/quote]QtScript used to be a separate engine but it is now written on top of JavascriptCore from WebKit so it has about the same speed.
As you said, no DOM there though.[quote author="DavidGOrtega" date="1294390387"]
I'm thinking in issolate the QWebPage in a executble accesed with the QProcess but I haven't found good points on it. That direction should solve aldso the Webkit memory leaks.Can you point an example to me?
[/quote]This sounds like a good plan IF you do not use shared resources like HTML 5 databases, cookies, etc.
I think youl should still evaluate QtScript.
[quote author="DavidGOrtega" date="1294390387"]
Anyway I can't undestand when documentation says "...widget-less enviroment..."
[/quote]peppe's description above is accurate. Widget-less does not mean not mean abstracted free from GUI dependencies.
Maybe you'll understand with examples?:
-to show the scrollbar in WebKit, we ask the application style to render them, so we rely on QStyle. QStyle is a gui element, it can be provided by the user, it is not thread safe.
-to render an image, we start by decoding them onto pixmap. Depending on the graphics engine, the pixmap can be a platform pixmap (XPixmap for example). Those are totally unsafe in threads.You can use QWebPage without a widget, for example you can render the content on a QImage and print it. BUT, this does not prevent you from relying on all the basic GUI infastructure needed to render the page.
-
Hi Benjamin,
I evaluated QScriptEngine from the very beginning, as I stated there is no dom in QScripEngine and thats pretty bad for me actually, but the main difference for me is the speed.
I know that both engines comes from the JavascriptCore, in fact I don't know why they even don't use the same objects... one returns QVariant an the other is QScriptValue, I prefer to have the core and the browser be talking the same... but as I stated also QScriptEngine is much slower, probably because the debugger that has inside...
If you evaluate a wrong javascript in both QScriptEngine is returning you a failure message and QWebFrame no...Just try
@for (var i=0; i<50000000; i++)
{
1+1;
}@and you will note the difference in speed between both...
-
On which version of Qt?
-
bq. On which version of Qt?
4.5.3
-
[quote author="DavidGOrtega" date="1294501236"]bq. On which version of Qt?
4.5.3[/quote]
This was not based on Javascript core. See "http://labs.qt.nokia.com/2009/11/23/qtscript-in-46/":http://labs.qt.nokia.com/2009/11/23/qtscript-in-46/
-
I see... thats why I noted it so slow... but the returned types are still different...
why aren't they returned as QVariant? -
[quote author="DavidGOrtega" date="1294502496"]I see... thats why I noted it so slow... but the returned types are still different...
why aren't they returned as QVariant?[/quote]Well, actually, returning QVariant was a big design mistake of QtWebKit. If the javascript team manage to integrate QtScript to QtWebKit, we will deprecate the return as QVariant.
Simple example you can't do with QVariant:
-return a Javascript object and interact with it (call functions, set properties, etc)
-return a JS function() and then call it from C++, or even pass it back to the engine