PureBasic Forums - English

I have also included a minimal example in the Zip file, which demonstrates how to load the DLL, create a new SWV control, and free it up before exiting the program.
A note on the UI: it's made up of standard HTML / CSS, which should make it relatively easy to build your own UIs if you have some basic experience with those languages.

Also have a look at the SWV_Demo1 source code, which should be fairly easy to follow.
Of special importance is the #SWV_JS_EVENT event which lets you easily catch and process events raised from the UI.

Feel free to play around with those things and share additional examples here

Demo updated!

- Added a Hello world program
- Updated the existing examples
- Added SWV_SetDOM and SWV_GetDOM to the library functions

SWV_Demo1.pb shows how to use the new SWV_SetDOM and SWV_GetDOM functions.

I'm not sure I will make a Chromium version anymore. For desktop UI rendering purposes (*), I am finding that the native rendering engines (Trident on Windows, Webkit on Mac and Linux) are more than powerful enough.

Does anyone see some good reasons that could justify spending time on a Chromium version and add 120MB of extra bloat to PB programs?


(*) Of course, for web browsing, it would be a very different story.

Hi firace,

I personally would not use a GUI engine that adds 120 MB to my PureBasic program.

It seems to boil down to Web Kit v Trident.

Would it be good if both GUI Engine and WebViewer were be based on the same platform? Would that mean more familiarity with the coding?

Web Kit
+ Good HTML5 compliance (possibly better integration with JavaScript libraries?)
+ Used for PB WebViewer Gadget on Linux and Mac
+ A Web Kit based WebViewer is available for Windows (by RS Basic)
- GUI Engine not available

Trident (Internet Explorer)
+ GUI Engine available (by Firace)
+ Native to Windows
- WebViewer unusable with modern websites
- Chromium being used for basis of MS Win10 Browser instead of their own tells it's own story
- Potentially limited life / no major compliance updates

So - what about a GUI Engine based on Web Kit? Would that be the best of both worlds? Or is Web Kit similar to Chromium, too bloated?

I really like the idea of being able to work with an enhanced GUI, but I don't like the idea of being reliant on a Lib/DLL. Disasters have happened in the past, so once bitten, twice shy. If it was built into PB........

IdeasVacuum wrote:It seems to boil down to Web Kit v Trident.

Would it be good if both GUI Engine and WebViewer were be based on the same platform? Would that mean more familiarity with the coding?

Not necessarily - modern UI engines often only use elementary constructs of HTML / JS / CSS, for which coding syntax is identical across all major implementations (including IE11), as far as I know.

Web Kit
+ Good HTML5 compliance (possibly better integration with JavaScript libraries?)
+ Used for PB WebViewer Gadget on Linux and Mac
+ A Web Kit based WebViewer is available for Windows (by RS Basic)
- GUI Engine not available

Trident (Internet Explorer)
+ GUI Engine available (by Firace)
+ Native to Windows
- WebViewer unusable with modern websites
- Chromium being used for basis of MS Win10 Browser instead of their own tells it's own story
- Potentially limited life / no major compliance updates

So - what about a GUI Engine based on Web Kit? Would that be the best of both worlds? Or is Web Kit similar to Chromium, too bloated?

I really like the idea of being able to work with an enhanced GUI, but I don't like the idea of being reliant on a Lib/DLL. Disasters have happened in the past, so once bitten, twice shy. If it was built into PB........

Yes unfortunately WebKit is as bloated as Chromium:
For instance, a Hello world example based on RSBasic's module is about 150MB for the x86 version and almost 190MB for the x64 version! Which does not really fit PureBasic's small binary size and optimized code philosophy, IMHO. Also, the module still lacks some essential functionality to make it usable as a UI engine for PB, in its current version.

If Microsoft releases a built-in Chromium based webview control, things will be interesting, but that might probably be limited to Windows 10 only.

I think the main problem is not the exe size but the RAM usage 40MB for Trident and 150MB for Chromium aprox. for a Hello World.

Justin wrote:I think the main problem is not the exe size but the RAM usage 40MB for Trident and 150MB for Chromium aprox. for a Hello World.

Trident's RAM usage is even lower than that when using local resources - For the SWV demo it's about 9MB here.

It's acceptable for nowaday standard.

firace wrote: Trident's RAM usage is even lower than that when using local resources - For the SWV demo it's about 9MB here.

Then it's pretty good. I was wrong with Chromium, a hello world app with a local resource takes about 70MB.

firace wrote:I'm not sure I will make a Chromium version anymore. For desktop UI rendering purposes (*), I am finding that the native rendering engines (Trident on Windows, Webkit on Mac and Linux) are more than powerful enough.

Oh dear, this project has just got as uninteresting as Sciter

firace wrote:Does anyone see some good reasons that could justify spending time on a Chromium version and add 120MB of extra bloat to PB programs?

It's not 'bloat', it's about the expected functionality from 21st century HTML/JS. If I can't be confident I can use any modern HTML5 widgets with it then I'm just not interested. Just one example - Tabulator which uses Promises, if I want to use that with Trident I'm going to need to find an acceptable polyfill. Extrapolate that for other widgets that rely on modern features of ES6 and pretty soon the whole UI is hanging together on a wing and a prayer.

And why are you obsessing about 120mb? Even with BT's shoddy broadband that's not even a 15 second download and it's barely a dot of storage on a modern drive. As for RAM usage have you ever noticed how Chrome renders complex pages really quickly whilst IExx is excrutiating (assuming IE can even render the page at all)? If that requires using more RAM so be it, that's what it's there for.

Kiffi wrote:I'm sorry to say it, but SWV scores too low on HTML5test

So what? It depends what the web page is doing. SWV will lose HTML5Test points for not supporting Dolby Digital audio even though this is not what SWV is designed to do. So the test is flawed because it tests for everything HTML5 even if you don't use all the elements of HTML5. It's like saying PureBasic is junk because it doesn't support Dolby Digital audio, even though I will never code an app that uses it.

For comparison, Firefox 74 (the latest) on Win 10 only scores 508 out of 555.

tried but none of the examples would run

[11:08:53] Waiting for executable to start...
[11:08:53] Executable type: Windows - x64 (64bit, Unicode)
[11:08:53] Executable started.
[11:08:53] [ERROR] SWV_MinimalExample.pb (Line: 8 )
[11:08:53] [ERROR] Invalid memory access. (write error at address 0)

thought then this was only x86 so i gave it a try and this is the error

[11:11:21] Waiting for executable to start...
[11:11:21] Executable type: Windows - x86 (32bit, Unicode)
[11:11:21] Executable started.
[11:11:21] [ERROR] SWV_MinimalExample.pb (Line: 11)
[11:11:21] [ERROR] Invalid memory access. (write error at address 10)
[11:11:25] The Program was killed.

exe just exits and none of the examples work because of the same address 0 error
what could it be?

both times i compiled with admin rights just in case but it didnt make a difference pb 5.7lts

superadnim wrote:tried but none of the examples would run

Thanks for your feedback.

A few issues have been fixed in the latest beta (released today).
Could you try again?

Note: this new beta will expire about 3 weeks from now.

Uploaded a new beta as the previous one expired.

The project is still alive, but development is a little bit slower these days.