QWebView widget

[Anonymous]

I Stefan,
It could so difficult to introduce a QWebView widget in future releases of ScriptCommunicator?
As you know this widget supports a quite complete html rendering engine (including CSS and javascript) and it could be useful for completing the SC capabilities. In particular it could be amazing to have the possibility to access to local files or to directly pass to the widget the HTML text to render. Let me know what do you think.
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Hi Pier,

this should be possible. But I will implement only a subset of the standard API:
- findText
- hasSelection
- isModified
- load->QString argument
- renderHints
- selectedHtml
- selectedText
- setHtml
- setRenderHint
- setTextSizeMultiplier
- setUrl->QString argument
- setZoomFactor
- textSizeMultiplier
- title
- url->returns QString
- zoomFactor
- back
- forward
- print
- reload
- stop

signals:
- loadFinished
- loadProgress
- loadStarted
- selectionChanged
- statusBarMessage
- titleChanged
- urlChanged

Do you need any other function?

Best regards,
Stefan

[Anonymous]

Hi Stefan,
this should be great.
I've checked one-by-one the routines/slots/signals you propose and I think that the QWebView class is quite complete for rendering web documents. I'm very excited to test the inner QWebView javascript engine and compare it with other tools I normally use (i.e. http://nwjs.io that is chromium/V8-based).
Thank you again.
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Hi Pier,

I have implemented the load function (see atachment). Now I see that the size of SC is 114 MB (43 MB before). I'm not sure if I want to increase the size of SC so much only for one script widget.

What do you think?

Best regards,
Stefan

[Stefan Zieker]

Hi Pier,

I have uploaded a test version which includes the web view (only the load function is implemented). You can find an example under exampleScripts\WorkerScripts\Gui.

Best regards,
Stefan

[Anonymous]

Hi Stefan,
I agree with you. I've read about the weight of this widget but no so much!
I Think that the size does not justify the introduction of this new functionality.
Do not worry. It was just for having a "all-inclusive" tool but there are other alternatives (including extrenal libs or plugins).
Thank you for your efforts.
Kindest regards,
Pier Andrea.

[Anonymous]

Hi Stefan,
I've tryed your demo (Thank you) and I admit that the "temptation is great".
It works very well an it is fluid.
The idea to have the possibility to program in javascript at server-side (SC) and interact with an incapsulated browser (also scriptable in JS) is fantastic Mainly for the possibility of bypassing the net with local HTML strings (Desktop HTML5 apps). In fact it is a complete HTML5 dev lab.
I think that, at moment this suggestion can "wait in the corner" and it could be no so difficult to implement it in future SC releases. Another alternative could be to start a small SC spinoff for HTML visualization interfaceable exclusively with SC (just an exe + few dlls downloadable separately).
Thank you again, you're great.
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Hi Pier,

I have uploaded a new test version which implements WebView as a custom script widget. You can find an example under exampleScripts\WorkerScripts\CustomWidget\webview.js.
To execute the script you have to add the libraries from the WebViewLibs folder to the SC folder.

Now you can use the WebView without increasing the size of the standard SC. Keep in mind that the custom script widget idea was yours. What a great idea :-).

PS: Only load is implemented yet.

Best regards,
Stefan

[Anonymous]

Hi Stefan,
thank you again.
I'll test the new test release asap this morning.
Kindest regards.
Pier Andrea.

[Stefan Zieker]

Hi Pier,

the current test version contains a bug. You can not restart the script which contains the web widget (you have to restart SC).

Best regards,
Stefan

[Anonymous]

Hi Stefan,
I'll consider your observation during prelimiary tests.
Thank you..
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Hi Pier,

I have uploaded a new pre-release which includes the fully implemented ScriptWebView. You can find the API in CustomWidget\WebView\readme.txt.

PS: You can restart the script now.

Best regards,
Stefan

[Anonymous]

Hi Stefan,
I did preliminary tests on the new WebView component and it seems to work very weel.
The integration solution in the SC structure is amazing. Did you internally changed SC for customizing it to the new component or the entire work is at plugin level (i.e. as the LED component)? In the second case the (compiled) plugin could be integrated (as optional extension) also in future SC releases without further efforts in this direction!
I'll start to work on passing HTML strings Tomorrow.
Thank you again.
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Hi Pier,

It's a custom widget (like the LED component) therefore I did not change SC.
I will upload the necessary libraries for Windows, Linux and Mac tomorrow (under Files\CustomWidgets\WebView).and add this download location in the readme.txt of this component.

Best regards,
Stefan

[Anonymous]

Hi Stefan,
a preliminary example.
Try to manually modify the HTML source and see the rendered page... all changes wil be overwritten by moving the sliders.
Unfortunatly every try of using the .seHTML() routine resulted in a crash of SC. The disk access will be excessive by using the .load() function.
Please check this if you have time.
Kindest regards.
Pier Andrea.

ps. the fact that the webKit widget is a plugin made without SC modification is a great news because it demonstrates that SC is fully expandible and customizable with no further changes to the core infrastructure (at moment). I'm very happy about this.

[Stefan Zieker]

Hi Pier,

I have fixed the bug. In the attachment you can find the corrected dll and your project with setHtml.

Bst regards,
Stefan

[Anonymous]

Hi Stefan,
Thank you for the fix, now it is perfect!
Yestarday I've tryed to modify the plugin dll without success. Can you upload the WebView plugin source code just to see your fix?
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Best regards,
Stefan

[Anonymous]

Hi Stefan,
thank you for the source. I found the differences.
I started to play with .setHTML path for the asynchronous loading of external files and, after several trays, I've fond this solution:
1) create a browser-side javascript: script.js and put it inside the /JS/ folder (relative to your script). This is the content of the file:

function test(i) {
    return i * 5;
}

2) create the HTML source dinamically with SC and insert the following line in the HEAD section:

<script src="js/script.js" type="text/javascript"> </script>

3) call the test() routine by inserting the following string in the HTML body:

<script> alert(test(20)); </script>

4) pass the HTML page source string to the WebView widget in this manner:

 UI_webView.setHtml(myHTMLSource,"file:///"+scriptThread.getScriptFolder()+"/");

The code inside the /JS/script.js file will be executed!

For me this potential It is very important because you could USE all the available Javascript code at browser side (i.e jQuery etc.) entending drammatically the power of SC.
In the same manner you can load images and other HTML objects (i.e. CSS files etc.).

Of course you can create browser-side Javascript code dinamically by re-using SC routines (as discussed previously about canvas objects).

Thank you Stefan for this possibiity.
Kindest regards,

Pier Andrea.

ps. I'll post a complete example asap

[Anonymous]

Hi Stefan,
I've found your new WebView component (+libs) release. The test version of SC is not more necessary, Can I merge the new WebView release with SC 4.00 right?
Thank you.
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Hi Pier,

just copy the dll's to the current version (4.00) and your script should run.

Best regards,
Stefan

[Anonymous]

Hi Stefan,
I've played a little bit with WebView component and I've found a new interaction level.
In attachment you can find the new version of the component with a new WebView routine:

QString evaluateJavaScript(QString clientJSExpression)

In the sample you can see the amazing interactions are now possible between SC and the JS interpreter inside the WebView component. Of course you can change HTML elements without reloading the page and access virtually to every value inside the client interpreter and the HTML page. In this manner we can reuse all the Javascript code written for browsers with a high speed of execution.
Let me know what do you think.
Kindest regards,
Pier Andrea.

[Stefan Zieker]

Hi Pier,

as I said before, you have really great ideas! I have put your project to the SC examples.

Best regards,
Stefan

[Stefan Zieker]

Hi Pier,

I added a print function (and changed the name of the library: qwebviewpluginplugin->qwebviewplugin).

Best regards,
Stefan

[Anonymous]

Hi Stefan,
thank you.
My "last" idea about WebView is to allow to call a SC routine from inside the Javascript interpreter, just to simulate a callback and an interaction from inside the web page.
This could be implemented in SC as a simple signal routine with a simple string argument from the WebView component in the similar manner you implemented the signal titleChangedSignal(QString).
The string argumet could be then parsed inside SC as a command-line.
I've found an example (in attachement) for doing this.
Please let me know what do you think about and if you want work on it, else I'll start to develop this functionality (addToJavaScriptWindowObject()) this afternoon.
Kindest regards,
Pier Andrea,