Qt 4.7 WebPage is a widget??

andre · wrote on 5 Jan 2011, 15:35

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 · wrote on 5 Jan 2011, 16:52

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

DavidGOrtega · wrote on 5 Jan 2011, 17:26

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 · wrote on 6 Jan 2011, 01:19

[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 · wrote on 6 Jan 2011, 09:51

[content removed - copy post - Alexandra]

DavidGOrtega · wrote on 7 Jan 2011, 08:53

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 · wrote on 7 Jan 2011, 15:17

[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 · wrote on 8 Jan 2011, 14:23

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 · wrote on 8 Jan 2011, 15:00

On which version of Qt?

DavidGOrtega · wrote on 8 Jan 2011, 15:40

bq. On which version of Qt?

4.5.3

benjamin.poulain · wrote on 8 Jan 2011, 15:44

[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 · wrote on 8 Jan 2011, 16:01

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 · wrote on 8 Jan 2011, 16:08

[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