Qt 4.7 WebPage is a widget??
-
[quote author="DavidGOrtega" date="1294232764"]
Be or not thread safe is not a big deal actually, the key thing is why the compiler is telling that. It's supposed that QWebPage is widget free, if not Qt documentation should not say that.
[/quote]Widget free in the sense that you do not need anything on screen to render the content. And you can implement your own QWidget on top instead of QWebView. We still need widget to render the form elements in the page.
I do not consider this as a bug. Running WebKit in a secondary thread is a really bad idea.
-
bq. I do not consider this as a bug. Running WebKit in a secondary thread is a really bad idea.
They are different isolated instances and they are not race problems involved...
In fact, I believe that QWebView runs different QWebPages instances in different threads.
Why exactly is a bad idea to run a QWebPage in a thread? -
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 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