@Todd, @Russ, yes, with Gtk3 it's a bit harder than I expected.

Gtk3 has a main message loop gtk_main() which, as it is being used in the webview library that I chose, blocks Pharo completely while webview window is active. On Windows, the webview window in general works without engaging the main message loop, but windows implementation doesn't rely on Gtk3 but on Edge.

On Linux, I firstly tried to put this webview library into a separate thread (a worker with headless image), however in this kind of setup the callbacks from the library cannot reach Pharo main thread. I solved this by exposing two additional Gtk3 functions in webview library, gtk_events_pending() and gtk_main_iteration() which enabled the construction of main event loop in Pharo that I run on the Idle Process priority level so that it doesn't take 100% of the processor time, like this:

proc := [[ true ]

whileTrue: [

(wv ffiEventsPending = 1) ifTrue:

[wv ffiRunIteration].

Processor yield.

]] forkAt: Processor lowestPriority.

So I don't need to run the webview library in separate thread, which is a bit simpler, and the callbacks work as they should. Now I just have to create some signaling so that Pharo will know if the user closes the webview window, and check if two Pharo classes that I already have (WebView and WebViewCallback) will suffice for these additional complications.

If anybody has a better idea for main loop implementation, I'm opened to suggestions :-)

The webview library that I chose uses Cocoa on MacOS, so no Gtk3 there. I hope that it will not be too difficult and that the above "one thread approach" will be OK for MacOS, too. Gtk3 was quite challenging, I was also considering to drop whis webview library and use gtk-bindings for Pharo directly, however then I would not be consistent also for Edge and Cocoa (in using one "umbrella" library). As far as I know, the webview general  intention is to use the native GUI technology as much as possible.

Best wishes,
Tomaz

Short report on webview porting:

• on Windows (Edge, Edge/Chrome) it works single threaded, it is more or
  less done, needs some rigorous stability testing,
• on Linux/Ubuntu (gtk3, webkit2gtk) almost done, it works as a separate
  TFWorker thread, still needs some process status checking if webview
  window is closed by user.
• on MacOS (Cocoa, WebKit) I got hold of an older Mac (Sierra) where
  WebKit doesn't support clipboard operations, but I have made a dynamic
  library without clipboard support just to continue the development. If
  anyone is curious, for compilation you need gcc (available here:
  https://github.com/kennethreitz/osx-gcc-installer). Then get webview.h
  and webview.cc from https://github.com/webview/webview and compile it
  with:

c++ -dynamiclib webview.cc -std=c++11 -framework WebKit -o
libwebview.dylib

After some more tests on Windows and Linux I'll pack all the libs on
GitHub and update the readme.

Happy holidays,
Tomaz

Dear all,

Pharo-Webview works on Windows 10 64-bit and Linux 64-bit (tested on
Ubuntu 20.04). The needed webview.so dynamic library is available within
the repository at https://github.com/eftomi/Pharo-Webview. On Linux use
headless VM.

There's also a webview.dylib for MacOS if someone wants to try it (built
on Monterey), however I wasn't successful on this platform, despite the
fact that I tried TFWorker and TFMainThreadRunner approaches, too. I'm
also not keen on Cocoa.

The library itself lacks a better support for webview create-destroy
mechanisms although it could be upgraded. I achieved my needed
functionality and unfortunatelly don't have time to continue. Maybe I'll
continue in next months, but according to my experiences so far it would
be better to choose a slightly heavier but cleaner Photino
(https://www.tryphotino.io/) or something else. Or maybe to work on pure
Pharo approach :-)

One of the interesting challenges is a double nature of Pharo -
interactive and "headless" mode - meaning that the application runs
without Pharo GUI. It'd be nice if both approaches would be possible.
The library that I used builds on the headless idea, where the main GUI
loop is supposed to be taken over by the webview, which is the main
reason for "create-destroy" challenge if you use it interactively. This
multiplied by USER32.DLL, Gtk3, and Cocoa ...

Best wishes,
Tomaz