Cells using custom renderers showed useless tooltips with the debug
representation of wxCustomRendererObject, which were worse than useless,
so avoid showing them.
Contrary to what might be expected, this can't be done by overriding the
specific tooltip-related delegate method, because these tooltips come
from NSTextFieldCell itself, so we need to prevent it from showing them.
Closes#24370.
Include wx/hashmap.h in utils/ifacecheck/xmlparser.h itself instead of
relying in the including file to do it because ifacecheck.cpp did not.
Closes#24359.
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.
Somehow, for some combination of characters, the native control didn't
show anything at all in the control unless its size was one bigger than
the size we computed. E.g. adding the following code to minimal sample:
auto p = new wxPanel(this);
new wxStaticText(p, wxID_ANY, " AI", wxPoint(10, 10));
new wxStaticText(p, wxID_ANY, " AJ", wxPoint(10, 40));
new wxStaticText(p, wxID_ANY, " AK", wxPoint(10, 70));
new wxStaticText(p, wxID_ANY, " BI", wxPoint(100, 10));
new wxStaticText(p, wxID_ANY, " BJ", wxPoint(100, 40));
new wxStaticText(p, wxID_ANY, " BK", wxPoint(100, 70));
showed just a "hole" instead of the " AJ" string, even though all the
others appeared correctly (observed under both Windows 10 and 11, at
standard and 200% DPI).
This looks like a bug both in our code (because we seem to not be
computing the text extent correctly) and in the native control (because
it should still show at least something even if the last pixel doesn't
fit instead of showing nothing at all), but it's not clear how to fix
the former and there is nothing we can do about the latter, so add an
extra pixel to fix a pretty bad user-visible problem.
wxClientDC already uses the font of the associated window by default, so
there is no need to set it explicitly.
No real changes, this is just a micro optimization.
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.
