gstreamer creates a new connection to the wayland display by default, and
gst_video_overlay_set_window_handle() only works if both the parent surface
(part of the gtk window) and the gstreamer surface are on the same display,
so we need to tell gstreamer about our wl_display when it asks
Otherwise wxDynamicCast-ing wxAuiNotebook to wxBookCtrlBase didn't work
(even if the more usual and useful upcast did still work).
Add a unit test for this.
b376d1402b accidentally broke columns
with wxIcon type. Contrary to that commit's assumption, operator<<
cannot convert wxIcon to wxBitmap and asserts:
src/common/bmpbase.cpp(33): assert "variant.GetType() == "wxBitmap"" failed in operator<<().
Fixed by restoring explicit conversion.
Include the version and flavour in the target name, no need to rename anymore.
Add the wxrc symlink to extra uninstall files, not the actual target name.
wxTranslations needs the information that user's default language is
used; in particular, it may choose to use a cascade of user-preferred
languages to choose the best UI language.
This was accidentally broken by
18bf718f60 which changed the logic to
fill shortName from the builtin database. This consequently changed
wxTranslations to use only the single detected language and ignore
user's preference cascade.
Closes https://github.com/wxWidgets/wxWidgets/pull/2385
In newer doxygen versions, the label was being used as the caption
for the image and not appearing in the 3rd column. The only way to
really fix this seems to be to make the image the last column so that
it doesn't eat the remaining text (there is no way to escape it
apparently).
This is the case for wxMSW implementation and while the other ones seem
to accept 1 or 2 points too, document the most stringent requirement,
especially because not satisfying it results not "just" in assertion
failure, but also in a crash in wxMSW.
This should obviously be improved further by, at the very least, using
wxCHECK and not wxASSERT in wxMSW code or, maybe, actually handling the
degenerate cases there if all the other ports really support them.
See #19172.
There doesn't seem to be any reason to only forward CHAR events, but not
KEY_{DOWN,UP} ones, so do the same thing for the latter ones too.
This allows to get rid of GetMainWindow() call in wxDataViewCtrl unit
tests, as wxEVT_KEY_DOWN are now correctly received in the control
itself and not just its main window.
This makes several methods that didn't have any effect before work
correctly, including SetToolTip(), whose effect is now shown in the
sample, but also SetCursor() and SetLayoutDirection().
Some methods would now actually work too well: SetForegroundColour() and
SetBackgroundColour() implementations in wxCompositeWindow apply to all
sub-windows, but in wxDataViewCtrl they are only supposed to affect the
items, but not the header, so we need to override them to prevent the
base class version from being used. It is still preferable to explicitly
disable these two methods and inherit all the other ones (including any
possibly added in the future) from wxCompositeWindow to implementing all
the methods manually in wxDataViewCtrl itself.
Use the just added wxEventObjectOriginSetter to set the event object and
ID to that of wxCompositeWindow itself, rather than that of the child
window where the event had actually occurred.
This RAII helper can be used to temporarily change the event object and
ID of a wxEvent and will be used when redirecting events to make events
from one object to appear as coming from another one.
Explicitly document that wxDataViewRenderer::SetValue() is never called
with null values (if we ever really need this, we should add a separate
ClearValue() method) and also document that MakeHighlighted() both
receives and must return a non-null value (the latter is required
because the returned value is passed to SetValue()).
See #18934.
This reverts commit f68c88b8d2 which
doesn't seem necessary any longer: the originally observed problem can't
be reproduced in contemporary macOS versions (10.14+), while calling
SetValue() even for null values results in asserts from several
renderers which don't expect this to happen.
This commit is best viewed ignoring whitespace-only changes.
Closes#18934.
Connect to key-{press,release}-event on the "focus widget" rather than
the main widget, to ensure that we get them before the native control
does and so can generate the key events even for the keys handled by the
control internally.
This allows to get events for the arrow keys in wxDataViewCtrl, for
example, while previously these keys were consumed by the control
itself, as could be seen with the following patch to the sample
---------------------------------- >8 --------------------------------------
diff --git a/samples/treelist/treelist.cpp
b/samples/treelist/treelist.cpp
index af6905cecb..74894cc9a9 100644
--- a/samples/treelist/treelist.cpp
+++ b/samples/treelist/treelist.cpp
@@ -349,6 +349,10 @@ bool MyApp::OnInit()
sizer->Add(textLog, wxSizerFlags(1).Expand());
SetSizer(sizer);
+ m_treelist->GetView()->Bind(wxEVT_KEY_DOWN, [](wxKeyEvent& e) {
+ wxLogMessage("Key in tree: %d", e.GetKeyCode());
+ e.Skip();
+ });
// Finally show everything.
Show();
---------------------------------- >8 --------------------------------------
Pressing arrow keys didn't generate the expected message before (unless
the focus was on the control header and not on the main area itself).
This may fix similar issues with other controls setting m_focusWidget as
well.
Calling ReleaseMouse() from wxEVT_MOUSE_CAPTURE_LOST handler could
result in bogus asserts about ReleaseMouse() reentrancy because the
function generating "capture lost" events in wx itself wrongly set the
wxMouseCapture::changing flag, instead of just examining it, as it was
supposed to do.
This corrects a problem introduced back in b0ad1918b9 (No changes, just
use wxRecursionGuard instead of manual boolean flag., 2013-08-18) which,
contrary to the commit message, did change the behaviour by replacing a
simple test with the use of wxRecursionGuard here.
This was also changed in 3c28244806 (Improve wxGrid appearance in dark
mode under macOS, 2020-08-07) but there doesn't appear to be any good
reason to do it as wxSYS_COLOUR_3DDKSHADOW is the same as the previously
used wxSYS_COLOUR_3DSHADOW (a.k.a. wxSYS_COLOUR_BTNSHADOW) under Mac, so
this didn't change anything there -- but did make the shadows darker and
hence more pronounced and more noticeable under MSW.
Undo this change to restore the old and nicer looking appearance.
The changes of 3c28244806 (Improve wxGrid appearance in dark mode under
macOS, 2020-08-07) resulted in using white highlight colour over white
background under at least MSW and probably elsewhere, making the grid
cursor invisible by default.
Fix this by using wxSYS_COLOUR_WINDOWTEXT which must contrast with
wxSYS_COLOUR_WINDOW used for the background colour.
This isn't needed when the comment comes right before the define,
and also in newer doxygen versions it causes the __WXDEBUG__ macro
to be not documented because it interprets @def __WXDEBUG__ as being
the WXDEBUG macro instead.
This provides a less intrusive, and also usable by the end users rather
than only by the developers, way of doing the same thing as the just
added wxSizerFlags::DisableConsistencyChecks() does.
