Use correct content type when creating binary secrets to prevent
libsecret from munging them.
Also update the sample to show more functionality.
Closes#24351.
Closes#24352.
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.
Correct the documented return type of this function to match its actual
type to fix a problem introduced in the recent f24b3d5483 (Save last
wxSplitterWindow position before it was unsplit, 2024-02-12).
See #24329.
Closes#24347.
Improvement to building Chromium using CMake: detect unknown build
configurations and make known "RelWithDebInfo" and "MinSizeRel" work
correctly.
See #24354.
No real changes, just rebake all the makefiles after the addition of
wxwin.extraLdflags, which results in an extra space even when these
flags are empty in webview-chromium branch.
This should have been done in f37401dde3 (Merge branch
'webview-chromium', 2024-01-19)
This test just doesn't want to work when run on GitHub CI under wxGTK2
even though it works perfectly locally. So enable the test at least for
all other ports.
A generic multi-select wxListCtrl did not deselect a single selected
item that did not have focus when the user single-selected another
item.
This fixes a regression introduced in fedc80eee3 (Improve selection and
focus events generation in wxGenericLisCtrl, 2020-10-10).
Closes#24312.
We need to connect these events to the internal GtkToggleButton taking
up the widget area and not the parent widget itself, which never gets
these events.
Closes#24295.
Mouse motion events happening over GtkEntry icons are consumed by this
class "event" callback, which simply returns GDK_EVENT_STOP for them if
the icon is insensitive (which is the case for GtkSearchEntry) and so
our "enter-notify-event" callback is never called.
Fix this by handling "event" signal ourselves and generating
wxEVT_ENTER_WINDOW from it if necessary.
Doing this required adding a global pointer to the window currently
under mouse, which is also used for generating wxEVT_LEAVE_WINDOW if
necessary.
See #24245.
This ensures that the expected events are given even after the widget is
recreated due to a change of some controls on its page (and not because
it's recreated by one of the menu commands in the parent frame).
We also don't need to connect to these events from WidgetsFrame any
longer (and, in fact, doing it would be wrong as we'd connect twice),
which simplifies its code.
No real changes, just move the function connecting to the widget events
from WidgetsFrame to WidgetsApp to allow reusing it from outside
WidgetsFrame in the next commit.
GTKIsOwnWindow() doesn't always return the correct result, i.e. it
doesn't recognize all windows that a GTK widget is made of as being
"ours", so checking for this resulted in wrongly ignoring some events.
And this check doesn't seem to be actually necessary, as we shouldn't be
ever called by GTK for the windows that are not ours, so just remove it.
See #24245.
Recent changes of cc9f9af400 (Flush wxLogGui before showing a modal
dialog, 2024-01-20) resulted in a (harmless) assertion failure in
wxModalDialogHook::Register() if the application created more than one
wxLogGui object.
Fix this by only registering our hook when the first wxLogGui object is
created and not for each of them.
See #24231, #24228.
Don't reset the selection in a generic multi-selection wxListCtrl while
Ctrl or Shift key is pressed to be consistent with wxMSW behaviour.
This commit is best viewed ignoring whitespace-only changes.
Closes#24332.
