@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](https://github.com/webview/webview) 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