Ensure that the sample can run using wxWebViewChromium backend out of
the box by setting things up so that it can find the CEF files. Note
that we use symlinks instead of actually copying these files, to avoid
wasting so much disk space (CEF libraries take more than 1GiB).
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.
This can be useful for diagnostic purposes and looks better than "0.0"
in the webview sample.
Notice that currently we return the compile-time version and not the
run-time version that could be retrieved using cef_version_info()
because this is simpler and we shouldn't be ever using a different
version from the one we were compiled with anyhow.
Modify the sample to show the correct value of the user agent when using
WebKit backend as this got broken by calling it inside an event handler
executed later but before the idle event handler could dispatch the
result of JS executed from inside WebKit AddScriptMessageHandler()
implementation, resulting in misinterpreting this result ("{}") as the
user agent string.
The real fix is, of course, to deal with the JS execution results coming
out of order in some way.
It is now defined as
@executable_path/../Frameworks/Chromium Embedded Framework.framework/Chromium Embedded Framework
in the framework itself, which means that we don't need to change it at
all for the main application and the wx library it uses.
We still need to change it for the helper application, but the command
doing it must be adjusted.
wxWebViewChromium creation is asynchronous and the object can't be
really used until OnAfterCreated() is called, so expose this in the
public API via a new event sent when the object becomes actually usable.
As a side effect, add a convenient wxWebViewEvent ctor taking wxWebView
as argument and calling SetEventObject() itself, instead of forcing all
code creating wxWebViewEvents to do it.
While the window was somehow resized on its own under Mac (and only
there) after the initial creation, it didn't have the correct size
initially if we didn't give it to it, so provide a Mac-specific
implementation of wxEVT_SIZE handler too, which fixes this and allows to
remove an ugly Mac-specific workaround from the sample.
Use variables defined in our .props files instead of hard-coded values
and use DPI aware manifest instead of using "compatibility" one with
which the sample didn't work correctly in high DPI.
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.
Log calls to some callbacks using "cef" trace mask.
To make these messages actually visible in the sample, use a log target
showing only debug messages and pass messages through to it from
wxLogWindow.
Add support for specifying multiple animations to allow automatically
showing a higher resolution version when using high DPI, just as it was
already possible with the bitmaps.
See #23817.
When testing downloading with wxURL and header Content-Length
is not available, display "n/a" as the file size instead of
the value of (unsigned long)-1.
Closes#23825.
Allow specifying multiple animation versions, for different resolutions,
when setting the animation to use via wxAnimationBundle class which is a
much simpler version of wxBitmapBundle used elsewhere.
This is not implemented for the native GTK version yet.
Update the sample, even though the difference in it is not really
noticeable as the "high DPI" throbber is just a scaled up version of the
existing standard DPI animation produced using gifsicle.
Instead of always scaling the single bitmap passed to it, allow passing
wxBitmapBundle and select the bitmap most appropriate for the current
resolution from it.
Closes#23813.
This reverts 5d630caabd (Make it enough to predefine only
wxUSE_DPI_AWARE_MANIFEST, 2023-08-23) and all the commits which tried to
fix the breakage caused by it.
While the original change had merit, it seems to be too difficult to fix
all our build systems to avoid embedding manifest when defining this in
the code, like samples/sample.rc does, so revert this change for now.
Maybe it can be reintroduced in the future after switching to some other
build system.
This clashes with the wx manifest which is getting included now after
the changes of 5d630caabd (Make it enough to predefine only
wxUSE_DPI_AWARE_MANIFEST, 2023-08-23).
- caret: Use the system color for window background instead of
hard-coded white.
- image: Use hard-coded black for the text drawing since all other
drawings on the image canvas use hard-coded colours too. The default
text colour was barely readable in dark mode.
- joytest: Use wxCYAN_PEN instead of wxBLACK_PEN to ensure the line is
visible both in light and dark colour system mode.
- ownerdrw: Use such background colour that there is good contrast
between text and background both in light and dark colour system mode.
- popup: Use such background colour for the pop up so that there is a
good contrast between text and background both in light and dark
colour system mode.
Closes#23773.
In the dialog, create the controls put in the static box sizer
with the sizer's static box as the parent instead of the dialog.
Improve appearance of custom drawn items in dark mode.
Closes#23765.
"base" library must always come last in the samples bakefiles as the
list of wx libraries to link with is generated when processing it, so
putting the "net" library after it had no effect.
See #23723.
This sample is the only one to use a GLU function too.
It would probably be better to drop GLU dependency entirely, but until
this is done (see #23721), do link with it.
This commit is best viewed ignoring whitespace-only changes.
Previously this was never done, as we couldn't determine if we were
using Cocoa or not at generation time, but we can determine it in the
makefile itself.
This samples used "wx_append" in its bakefile, but should be using
"wx_append_base", as it's a console application.
This fixes its build with makefile.unx, as wxUSE_GUI wasn't properly
defined as 0 before.
This is not needed when building as part of the build tree, as it's
already part of EXTRALIBS_OPENGL then, but is required when building the
samples against installed libraries.
This commit is best viewed ignoring whitespace-only changes.
This function should be used to get the parent for the custom controls
instead of relying on them being reparented under it by the code added
in the last commit.
Change the type of m_contents to be wxWindow and not wxPanel as it
doesn't really matter, but wxPanel is not fully declared in this header
while wxWindow is.
The code in b76ebc6 switched from wxList to std::vector but the changes
did not account that we must store the pointers to derived classes in
the entity list, not just the struct they derive from.
Closes#23582.
