This opens many customization possibilities beyond those provided by
wxWebView API and also allows to process CEF IPC messages much more
efficiently than what is possible using wxEvents.
Closes#24336.
Add new wxWebViewConfigurationChromium class which corresponds to the
"native" configuration used in the other backends and contains (some)
fields of CefSettings in this one.
This allows to use a helper process different from the main one on all
platforms, not just macOS, and can be preferable if the initialization
of the main process is too complicated to be easily short-circuited.
This prevents wxWebViewChromium from referencing debug-only functions
that are not defined in the release build of libcef_dll_wrapper.
Unfortunately, CEF build doesn't provide any way to detect if the
wrappers were built in debug or in release mode, so just assume the
latter and add --enable-cef-debug configure option to build with a debug
build of CEF wrapper if necessary.
Just include wxWebViewChromium in the webview library if it's enabled
during the build.
There doesn't seem to be any reason to build a separate library for it,
it's not really different from the other disabled by default wxWebView
backend (Edge).
And now that we don't need to link with an extra library, there is also
no need to have a separate webview_chromium sample, so just add a
possibility to run webview sample itself using Chromium backend by
setting WX_WEBVIEW_BACKEND environment variable.
Make browser creation actually work by postponing it until the host
window is realized and so has a valid X11 Window.
Remove unnecessary code manually creating GTK widget and just use the
standard wxGTK wxWindow instead.
Add code for setting the visual compatible with CEF to avoid X11 errors,
see https://github.com/chromiumembedded/cef/issues/3564, with many
thanks to Jiří Janoušek for finding and solving this problem originally.
Adjust the sample to handle wxWebView::Create() failure (not very
gracefully, but still better than just crashing) and to avoid using it
until it is fully created.
Update documentation to mention GTK limitations.
At least when using wxGTK Chromium helper process can't be executed once
GTK is initialized because doing this creates background threads and
Chromium code aborts if there are any threads running.
As we don't want to initialize CEF unconditionally before initializing
GTK in all applications (even those not using CEF), the only solution is
to detect if we need to run a Chromium helper process ourselves before
GTK initialization, i.e. before wxApp creation, which means that it
can't be done via the existing wxModule mechanism because modules are
initialized after creating the global application instance.
So add a way to hijack wxWidgets initialization entirely if some special
command line option (such as Chromium "--type=xxx") is specified and use
it in wxWebViewChromium to call CefExecuteProcess() before initializing
GTK or even wxWidgets itself -- as it won't be needed in a CEF helper
process anyhow.
