PureBasic Forum

+1

Okay, this is somehow limited. But regarding to this comparison I do not really see an issue. Many elements are done using CSS anyway and Sciter is WAY MUCH MORE than in PB dialogs (native, XML) was possible before.

Of course, if the PB WebGadget offers similar functionality, it also would be great. But as long as the Windows Explorer is used and the availability of WebGadget on Linux distributions is unclear and there is no proven and clean implementation of functionality on all three platforms, I'm not interested. If some WebKIT version was delivered with the same version and functionality on all three platforms, it also may be an option. So that we can manipulate the DOM from PureBasic or get events from WebGadget, it would be fine. I already lined out such solution a few weeks ago:
https://www.purebasic.fr/english/viewtopic.php?f=3&t=70755

I also would like that. But IMHO to integrate Sciter currently seems "closer to become realized" than such enhanced WebGadget...

Ok, I didn't get this so far.

No javascript means simply "game over" for Sciter!
What about the millions of JS frameworks available?

Maybe one of this is the right one?

https://webkit.org/
https://webkitgtk.org/
https://www.chromium.org/blink

Why not to use Electron "as it is" then?

Yet don't forget that main purpose of a browser is to provide secured browsing experience. Rendering stuff is its second goal.
So all these solutions (based on web browser engines) will run separate process (not even thread,sic!) for each desktop window.
And so UI<->PB communcation will always involve marshaling accros process boundaries.

Yet sciter.dll is 4.9 Mb and webkit and friends is at least 40 Mb.

You guys need to decide what you really need. Some things are in principle non-achevable with existing stabdalone-browser-that-pretends-to-be-embeddable.
As an examples...

1. With WebKit you cannot get anything close to this HTML window:

as you need DirectX for that.

2. Things that are achievable in web browsers by libraries are built-in in Sciter. As an example here is full example of syntax highlighting implementation in Sciter:

Can you do anything close to this in 40 lines of code in browser?

Great points c-smile

Also TIScript syntax looks very similar to JavaScript.

Without listing the world, what showstopper gadget is missing from sciter that would require augmenting with another JS lib? A quick browse shows a VirtualList array(DataGrid) is populated using TIscript.

Are you expecting 1 JS lib with all gadgetry in place?

A WebGadget

haha, you mean a JS-enabled WebGadget

Hello Andrew,


because Electron is programmed with JavaScript and not with PureBasic?

Moreover, the NodeJS overhead can be almost completely replaced by PureBasic-Commands.


You mean the window transparency? Admittedly, I'm not particularly interested in these effects, but if you want to have it: there are enough examples in the PB forums how to make a PureBasic window transparent.


there are thousands of useful JavaScript-Libraries and -Functions (also several syntax highlighter).


http://mbostock.github.io/d3/talk/20111018/collision.html

Can you do anything close to this in 75 lines of code in Sciter? (yes, I know that the code calls d3js - functionalities and is therefore so short, but with a browser that supports JavaScript this is possible, with Sciter it is not possible (correct me, if i'm wrong).)


Please don't get me wrong: I think your product is great, but I also think we are much more flexible and more independent with a WebGadgetEx()-Solution.

Greetings ... Peter

In webbrowsers, often new security holes are detected. So how secure is using such a proposed webgadget with extented functionality? I don't want to get headaches concerning the security of my programs, when they have a UI based on a webgadget, and there is a known security hole in the underlying rendering engine or something like that.

You propose to use WebKit that is around 90% of Electron size. So the question is about what to use in those 10%. My answer is: whatever already available as anyway your "Hello world" will take 40 or so megabytes and your nice small compact PB code will be shadowed by that mountain.



In order to achieve acrylic support (on Windows) your UI shall be purely windowless and use DirectComposition to render stuff on tree of screen Visuals directly (Sciter uses WS_EX_NOREDIRECTIONBITMAP). I doubt that PB can do that with any existing library. In any case GPU acceleration is mandatory these days. Modern high-DPI monitors increased number of pixels that need to drawn (a.k.a. rasterized) 4-9 times. Stuff that was working before with CPU rasterization (like GDI) are suddenly not moving on high-DPI - our CPUs haven't increased that much.



I am talking about built-in features for which you don't need any 3-rd party library.

As of that sample above... I know one project with Sciter that uses Box2D (A 2D Physics Engine for Games) - C++ library that is way more performant than any possible JS solution.
Sciter is an embeddable engine from the very beginning - it is easy to use in it existing code and libraries. Not JS ones but C++, C#, Go, Rust and so PureBasic.

Hello Andrew,

anyway, there's nothing wrong with having both.
I would be happy to have an extended WebGadget and Sciter.
But in the end, as always, it's Fred's decision.

Greetings ... Peter

I understand all the arguments forth and back, but finally, Sciter would be a HUGE step forward to get modern User Interfaces in PureBasic, scalable with DPI and rendering lightning fast. And finally, it is much smaller than embedding WebKIT etc. The only drawback in Sciter I see is the missing JS compatibility. But I also doubt that, from the UI point of view, this is mandatory. The existing Sciter customers are showing us great examples of what can be done. So, for enhancing PB Apps User Interface, I think Sciter is the best solution.

If someone needs a WebGadget with full blown JS and good integration to PB, Sciter will be wrong. For this, the existing Webgadget has to become extended and enhanced. I don't know if the current approach (use existing libraries) does fulfill the needs. On Linux, not all components may be available and on Windows, different Versions and IE dependencies may become a problem. I don't know. But for sure, the support of several features will be different on the three platforms and must be taken care of.

Thus, Sciter seems much more close to me and it also seem to fulfill many needs for modern UI. So going forward on that path would be great. Enhancing the existing WebGadget is a discussion since years and currently it does not look like this is easy...

Finally, it's Freds decision.

+1 from me.

So, Fred, did enough people offer their support to fund this feature (the native integration of Sciter)?