We can produce simpler and more readable PostScript code by doing
the calculations of Bézier curve parameters in the code instead
of delegating this task to the PostScript processor.
Drawing Bézier curves is supported natively in SVG so these curves
should be used instead of generic wxDC implementation based on
polygonal approximation.
Using c_str() for arguments to wxString::Printf(), Format() and
wxLogXXX() is useless since wx 2.9 days, so simply remove them.
No real changes, this is just a (long due) cleanup.
DoDrawSpline() implementations for all ports work for the number of points
>= 2 (for 2 points there is drawn a straight line) so we need to add checks
whether this requirement is met.
See #19172.
Instead of implementing MSW-specific code to handle HDC for GDI+ context
directly in wxGCDC delegate acquiring/releasing HDC to underlying
wxGraphicsContext. Decoupling GDI+-specific code from wxGCDC will allow
us to implement handling HDC in other graphics renderers in a clean way.
Enable ellipsization to show the items reasonably well even if they're
too long to fit into the available space -- without this, just the tail
of the long items was shown and shorter items could have been not shown
at all, as only the blank part of their label was visible.
Closes https://github.com/wxWidgets/wxWidgets/pull/2403
Co-Authored-By: Kent Tessman <kent@generalcoffee.com>
Co-Authored-By: Paul Cornett <paulcor@users.noreply.github.com>
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
They were incorrectly interpreted as mnemonics when drawing
wxCheckListBox items, which didn't make sense and was inconsistent with
the other ports and even wxListBox in wxMSW itself.
It also affected wxRearrangeCtrl under MSW, which uses wxCheckListBox
for its implementation.
Closes#19201.
Don't reset the labels windows size to the default value, it should stay
as 0 because otherwise we break the invariants
m_rowLabelWidth != 0 <=> m_rowLabelWin->IsShown()
m_colLabelHeight != 0 <=> m_colLabelWin->IsShown()
that the rest of the code relies on.
Closes#18904.
Consistently check that the index is valid in all ports, instead of
using hard-coded 255 rather than the actual number of colours in some of
them and forgetting to check that the index is positive in others.
Closes#19198.
This shouldn't really change anything, but is more appropriate and might
matter in the future if other event handlers are added to wxBookCtrlBase
event table.
This was broken in to 682cb8355c (Replace "sendEvent" parameter in
wxGridSelection with "eventType", 2020-08-21) which changed Select() to
take wxEventType argument but still passed it "true" in a few places.
Fix this and add a unit test verifying that this works as expected.
Ideal would, of course, be to avoid implicit conversions from bool to
wxEventType but making wxEventType anything other than int, for which
such conversions are unavoidable, is too backwards-incompatible to
seriously consider.
the Move handler apparently misses some resize events, so move the
gst_player_video_overlay_video_renderer_set_render_rectangle call
to expose_event_callback.
This is kept as a separate commit because it would be more efficient
to keep it in Move once we can catch that initial size change, so
this commit can get reverted then.
gstreamer is known to crash on xvimagesink if the main window is
wayland-native and DISPLAY is set: try to make it not load.
Also do the same for ximagesink just in case.
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.
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
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.
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 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.
