The change in the value can be greater than 1 when the arrows are held
pressed, contrary to what the logic of determining the wraparound added
in 086793ceef supposed.
Replace this with a check of whether we switch from the min value
directly to the max one or vice versa, which mostly works and avoids
asserts, even if it can still fail and produces wrong events when the
arrows are held pressed for long enough to increase the delta to the
range of the control, in which case we just can't distinguish between
wraparound and passing from min to max (or vice versa) in a single step,
which means that we have no way to determine the right event to send.
But producing a wrong event is better than asserting, so this still
counts as an improvement.
Closes https://github.com/wxWidgets/wxWidgets/pull/1764
See #17957.
Closes#18695.
GetTextObject() might return null, e.g. it does it for read-only
wxBitmapComboBox, so EnableTextChangedEvents() must account for this
possibility, as it's not really possible to avoid calling it in this
case, as it's called indirectly from e.g. SetSelection().
Check that the entry is valid before enabling or disabling events for it
to avoid several GLib assertion failures every time when e.g.
wxBitmapComboBox::SetValue() is called.
Closes https://github.com/wxWidgets/wxWidgets/pull/1756
At least one WM (KDE's KWin) does not generate X11 configure events when dragging
a window using gtk_window_begin_move_drag(). We need the configure events so we
can generate wxMoveEvent, which AUI needs in order to re-attach a floating pane.
This is functionally a revert of b8789b9d6f for backends other than Wayland.
See #18372#18669
This doesn't work anyhow, so it's better to prevent the code doing this
from compiling instead of getting run-time asserts or worse.
Also simplify construction of these events inside wxWidgets by passing
the window itself to the ctor instead of passing just its ID and calling
SetEventObject() separately later.
For consistency, do the same thing for wxNcPaintEvent too.
This is not the best solution, but getting dozens of lines of warnings
when compiling this file is not great neither and there doesn't seem to
be anything else to do about this.
Put common code from all the different ports into it.
This is not very useful right now, but it will allow to change this
function once, instead of applying the same change to all ports, in the
upcoming commit.
Ensure that the dialog is still alive when it gets the kill focus event
for its child which had focus just before the dialog was closed (or any
other events generated by this child when it detects that it's losing
focus, such as wxEVT_SPINCTRL) by resetting focus when the dialog is
being hidden and not when it's being destroyed.
This makes the events order more consistent with wxMSW but also, most
importantly, safer, as wxEVT_KILL_FOCUS handlers could previously easily
reference the fields of an already half-destroyed wxDialog-derived
object by the time they were run during wxTopLevelWindowGTK destructor
execution.
Closes#18145.
This makes more sense for a page of a GtkNotebook, which is always
positioned at (0, 0) relative to its client area, and is also more
compatible with wxMSW.
Closes#18548.
Closes https://github.com/wxWidgets/wxWidgets/pull/1670
Fix positions of the checkboxes drawn by wxGridCellBoolRenderer and
shown by wxGridCellBoolEditor so that there is no jump when starting or
stopping to edit grid cells with boolean values.
See https://github.com/wxWidgets/wxWidgets/pull/1662
This makes the checkbox look ugly as it's clearly not supposed to be
rendered without the border at all, so it's better to do nothing than
mangle its CSS.
It could be better to add some virtual GTKTurnOffBorder() method that
could be overridden to do nothing in wxCheckBox and we should consider
doing this if there are other classes for which wxNO_BORDER breaks their
appearance, but for now, as long as it's the only case in which we need
to do this, just turn wxNO_BORDER off when calling PostCreation().
This results in rather ugly checkboxes when the rectangle is too small,
and even "critical" GTK warnings with wxGTK 3, but is still arguably
better than drawing outside of the provided rectangle.
No real changes, just extract the same code used in both GTK 2 and GTK 3
implementations of GetCheckBoxSize() and DrawCheckBox() in a helper
class which is now just used from both places.
This makes the code more clear and hopefully easier to maintain in the
future.
Put GTK 3 version first in both functions instead of putting it in the
middle (!) of GTK 2 code in the former one for some reason.
No real changes, the code was just moved around (this commit is best
viewed with "git diff --color-moved").
Add ability to get the size of the checkbox without any margins by
passing wxCONTROL_CELL flag: this can be useful when the checkbox is
part of some "cell", e.g. wxGrid one, and doesn't need any extra margins
around it.
Currently wxCONTROL_CELL is only really used by wxGTK2 implementation.
The changes of 173f035bc2 resulted in
unknown warning group '-Wcast-function-type', ignored [-Wunknown-warning-option]
diagnostics from clang (even clang-10) and, presumably, also from
versions of gcc earlier than 8, which added this option, so use the
special wxGCC_WARNING_SUPPRESS_CAST_FUNCTION_TYPE() macro added in
ed01fede2e just for this instead.
No real changes.
Size should include border and padding. Margin values seem to be for a checkbox with text
label, so don't include margin. Check mark should be drawn inside border and padding.
Previously we added the extent of the text to the preferred size of a
spin button with 0 digits, but this didn't account for the fact that the
control still reserved enough space for 3 digits in this case, and so
the returned size was always too big than the required size by the width
needed to show 3 digits.
Fix this by directly asking for the size required to show the number of
digits corresponding to the given text size.
Note that ideal would be to provide GTK API at wx level directly, i.e.
allow to just specify the number of digits instead of the text extent.
But we still need to fix the already existing GetSizeFromTextSize()
anyhow, so do this for now.
See #18568.
Ensure that the entry is always (just) big enough to show any value
valid in this spin control.
This also ensures that GetBestSize() doesn't need to be overridden to
use GetSizeFromTextSize() any longer as the best size will be determined
correctly by GTK itself.
For GTK2, get the "inner border" the same way GTK does it. And for GTK3,
provide an actual implementation. Also, don't return a wxPoint for a size.
See #18567
Ensure that we set m_window in case of early return from wxWindowDCImpl
ctor, so that using e.g. wxDC::GetSize() works for wxClientDC created
for windows that hadn't been realized yet.
It might be possible to avoid this early return completely as the
comment explaining why we're doing it seems to be out of date: our
SetBackground() doesn't call wxWindow::SetBackground() (and it would be
exceedingly strange if it did), but for now just the bug without
changing anything else.
Closes#18569.
wxMemoryDC and wxScreenDC dtors were freeing a context they didn't own, potentially
causing a crash. Fixed by having the base wxWindowDC dtor free the context.
See #18566
This avoids glib warnings
object class 'GtkTextTag' has no property named 'underline-rgba-set'
when calling g_object_get() with older GTK and just avoids doing useless
work.
