Qt 4.7 WebPage is a widget??

dangelog

QWebPage is a GUI element (it uses pixmaps, QStyle and so on). In Qt you're not allowed to use any GUI elements from other threads but the main thread. That's it.

andre

Indeed. It sounds like in theory, running webkit in a secondairy thread could be a great idea. You can render a page into an image as a preview, for instance. Would be perfect to do in a background thread.

dangelog

In theory, making the GUI classes reentrant would be great. In practice, I don't expect it to come very soon... :)

DavidGOrtega

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...

benjamin.poulain

[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

[content removed - copy post - Alexandra]

DavidGOrtega

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

benjamin.poulain

[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.

DavidGOrtega

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...

benjamin.poulain

On which version of Qt?

DavidGOrtega

bq. On which version of Qt?

4.5.3

benjamin.poulain

[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/

DavidGOrtega

I see... thats why I noted it so slow... but the returned types are still different...
why aren't they returned as QVariant?

benjamin.poulain

[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