VAST Platform 2026 - No further WebView integration ?

[mar...@feldtmann.online]

As I noticed yesterday - I had hope, that the WebView is integration into the WindowBuilder and the AbtBuilder ... but nothing :-)

Marten

[Marcus Wagner]

Marten,

as far as I understood, WebView is offered on Android and iOS platforms.

Neither is currently covered by VAST (Mac support however is anounced).

Are you really asking for VAST to cover these platforms to support the integration of a widget there?

Kind regards

M

[mar...@feldtmann.online]

Well, I mean the feature "z.ST WebView Support", which is related to the feature of embedding the Windows Browser into your fat client application. I am missing an integration into WindowBuilder or the Abt-UI Builder - so, in a way of being end customer friendly.

Marten

[Marcus Wagner]

Dear Marten,

sorry, that I did not realize this recent feature from 2024 (VAST 13.0.0), thats my mistake. 

Anyway I want to expose my opion about its integration. I cannot estimate costs of impacts in WindowsBuilder, as this builder is currently out of my reach.

I would not expect Abt support, as the widget is violating Abt foundamental principles, like the platform independency, once being considered to be one of its important values.

In so far the name CwWebView is already doubtfull (in the sense of its Envy origins). It is not common - or coming from X-Motif, despite the prefix Cw - common widget.

Webview follows it own architectural considerations, not 100%ly matching the existing model.

Also consider e.g. the upcoming and already established bans (of such artefacts caused by security considerations - having two sides: 
certain pages cannot be shown or apps containing such webviews are considered unsecure (to avoid man in the middle attacks actively or passively).

Also integrating the MS edge browser through the backdoor and making inherently use of OLE internally might turn out risky.

Some thoughts to the end costomer friendliness, as making use of a very specialized platform specific widget requires to make compromises: during the graphical construction, what about placing CwForm widgets instead of CwWebview?

After fixing the UI construction, exchange the class reference temporarily/finally to CwWebview in the respective method code.

My personal estimate: I currently would not expect further support, as this component (Webview2)

° is still in development progress

° requires special debugging (SDK) and testing (Playwright, JS node) support.

° naturally provides its own process/thread model (in potential conflict to Smalltalk)

Perhaps all of my thoughts here are sounding negative, but I appreciate the general idea of integrating a view to a web page in an application.

I see this as an initial attempt to solve this request.

The future will turn out if this approach can stabilize and how it will develop.

Kind regards

M

[mar...@feldtmann.online]

Well, I use this feature already in my application ... and I am very satisfied with the possibilities it offers (and I use it within C# also - but there the Widget is very well integrated)) and I think - and I assume, that this might sound crazy - its the only possible way to get a portable UI among current platforms and perhaps future platforms of VASTPlatform.

By the way this is also a pretty good way to modernize old monolit WinForms applications ... and to transform them to .NetCore and more platforms (Windows, Linux and Mac),

I know, that this idea seems strange for VAST developers - but I went this way with Gemstone in the past (division of logic in Smalltalk and UI in JS) and even though it takes some time to find a nice programming model, I also started a conversion of a very old, very large C# program and yes its a possible way.

Perhaps strange, but a way to survive ...

Marten