Give a reasonable default size to wxPreviewCanvas and fit wxPreviewFrame
to its contents.
Remove the useless call to Fit() from SizerWithButtons: the size set
inside it was just ignored anyhow.
This also allows to stop hardcoding the size in the sample, so don't do
this any more.
See #22439.
No real changes, just remove the useless call which was left over the
very first version of this code added in 7bcb11d307 (Many changes to the
printing classes., 1999-03-25).
Don't hardcode 70px size for the combobox, but let it determine its own
size instead, as 70 may well not be enough, depending on the theme and
the font size.
Closes#22439.
This was recently broken by bffcb88266 (Optionally detect not filtered
GTK log messages, 2022-05-12), see #22424.
Fix it by providing a trivial "do nothing" version of LogFilterByMessage
even if we can't implement it -- this seems to be preferable to using
preprocessor checks in the code using it.
Closes#22434.
Don't use wxWithImages::GetImage(), which is limited to only a single
bitmap resolution, but use GetBitmapBundle() instead to ensure that we
show the representation of the bitmap appropriate for the current
resolution.
This would seem to be required for drawing it correctly in the disabled
state, for example, but is still insufficient to fix its appearance, at
least with GTK 3.
See #22431.
The changes of adb8bbab4d (Sort font names in the dialog showing them in
the font sample, 2022-05-12) didn't compile with wxUSE_STL==1 because
wxSortedArrayString doesn't inherit from wxArrayString in this case.
Fix this by using wxArrayString and its Sort() method instead.
The fix of a5a5b1bb15 (Fix restoring focus after showing native modal
dialogs in wxMSW, 2022-04-07) wasn't quite correct as it used the parent
window specified when showing the dialog, but it should have been using
the effective dialog parent, i.e. owner window in MSW terms.
Fix this by passing GetParentForModalDialog() to wxWindowDisabler, which
ensures that the preserve the same behaviour as before, including
refreshing the owner window after the dialog as dismissed -- which turns
out to be important because some existing code relies on this happening,
see #22362.
This commit should hopefully fix the last regression after d311c705d7
(Make native dialogs application-modal in wxMSW, 2022-04-01) and still
solve the original problem (see #11887), while preserving the original
behaviour when there is just one top-level window.
This makes the list of the fonts much more readable, compared to listing
them in essentially random order.
Incidentally stop using manual memory allocation to avoid giving a bad
example.
In the future it might be useful to run the code with WXTRACE=gtklog to
see if any GTK log messages we're filtering don't need to be filtered
any longer.
These messages are due to an assertion failure deep inside ATK which
doesn't indicate any real problem (as failure to get the label of an
already destroyed tab is normal and is already handled correctly in the
GTK code) and can't be avoided, so suppress them to avoid showing them
to the users who can't do anything at all about them anyhow, but can be
scared by the "CRITICAL" GTK messages.
Closes#22176.
Refactor the code to separate setting of the log callback from the
filtering decision.
Right now the only existing filter is the one just checking the log
level, which is used by GTKSuppressDiagnostics(), but this will allow
adding other filters in the upcoming commits.
Compare the row position with the number of rows, not columns, fixing a
regression introduced in 3719ab3725 (Add support for rearranging wxGrid
rows order interactively, 2022-04-02) (see #22260).
Closes#22420.
Closes#22423.
Unlike direct tests of __cplusplus, using this macro also works with
(recent enough, i.e. MSVS 2015.3 or later) MSVC versions, even if
/Zc:__cplusplus is not used.
This simplifies some checks and makes some other ones (notably the check
for C++20 used before wxALLOW_COMBINING_ENUMS macro definition) work
with MSVC versions with C++20 support as intended.
There is no need to check for the weird case of using a C++11 compiler
with C++98 standard library any longer, this is not supposed to happen
and we don't support macOS < 10.7 since a very long time anyhow.
Fix a layout issue when wxFlexGridSizer contains items that return true
from InformFirstDirection(), such as wxWrapSizer.
If didAdjustMinSize == true, the minimum width has probably changed, and
we should recalculate it. Otherwise we end up using incorrect delta in
DoAdjustForGrowables, which might push items too far to the right.
Closes#22421.
This was broken by the changes of 6383bc39ff (Add convenient
wxDCImpl::CalcBoundingBox() overloads and use them, 2022-04-30), fix it
by calling the overloaded wxDCImpl::CalcBoundingBox() instead of the
wxDC version for which the overloads were not added.
Closes#22418.
This is slightly more efficient and simpler than using a separate
critical section and can easily be done now that wxAtomicInc() returns
the new value.
No real changes.
This is easy to do and can be useful when using an atomic initialization
counter.
The only platform where not returning the new value might be more
efficient than returning it is Solaris which is not really relevant any
more and on all the other platforms the functions we were already using
provided this value already (or almost, in case of using gcc builtins,
when we just have to use a different one).
Use gs_initData.csInit only to ensure that we call wxEntryStart() once
even if there are multiple calls to wxInitialize() from multiple
threads, but don't keep it locked for the duration of that function as
this is unnecessary and results in -- probably benign in practice, but
still annoying -- warnings from the thread sanitizer about lock order
inversions due to locking csInit first before locking gs_mutexGui in
wxThreadModule::OnInit() and then acquiring csInit again while
gs_mutexGui is still locked in wxUninitialize().
This shouldn't result in any observable changes in behaviour.
The default type doesn't really matter after the previous commits, as
the renderer accepts both wxBitmap and wxBitmapBundle (and also wxIcon)
in any case anyhow, but it seems better to use the preferred type as the
default one.
Also make the documentation more useful, although an example is still
lacking.
Define wxBitmapBundleVariantData without using the standard macros that
only work for wxObject-derived classes, but using more or less what they
expand into.
This will allow using wxBitmapBundle with wxDataViewCustomRenderer
subclasses in the upcoming commit.
Allow using either wxBitmap or wxIcon in wxDataViewBitmapRenderer
independently of the type the renderer was created with because this is
convenient and there is no real danger in allowing to mix and match
bitmaps and icons together.
Override the just added IsCompatibleVariantType() to implement this.
Instead of checking for the exact variant type match, call the new
IsCompatibleVariantType() virtual function, which still does the same
check by default, but can be overridden to allow other types as well if
they're accepted by the renderer.
This will be soon used to allow accepting both wxBitmap (which must
still be accepted for compatibility) and wxBitmapBundle (which is the
simplest way to support high DPI) in wxDataViewBitmapRenderer at once.
HasValue() is already called by PrepareForItem(), so there is no need to
call it explicitly from wxGTK code, just rely on PrepareForItem()
returning false if there is no value to show -- we can skip the call to
GtkSetCurrentItem() in this case, this function is cheap, and we lose
more by calling HasValue() twice in the common case than we save on not
calling it.
No real changes.
