We often need the logical bitmap size when using it in size computations
involving window size, so add a function returning it directly to
wxBitmapBundle, similarly to wxBitmap::GetLogicalSize(), to avoid using
FromPhys() everywhere.
Also rename the existing wxBitmapBundle::GetPreferredSizeFor() to
GetPreferredBitmapSizeFor() to make it more clear that this is similar
to wxBitmap::GetSize() and so returns the size in physical units.
Closes#22056.
Performance tweak for samples/display, resulting in a much faster
application start, particularly when built in debug mode, when Windows
messages are dumped to the system debug channel for
inspection/diagnosis.
Speed up the Append() loop below by foregoing the repeated resizing of
the choice drop-down via repeated calls to GetBestSize() which happens
deep inside the Append() call chain and executes another inner loop
calling SendMessage() to get the control contents. (This exhibits
1/2*O(N^2) behaviour thanks to the linear growth of the length of the
inner loop to the length of the outer loop (= number of items to add),
while it is re-executed for every new added item.)
With the 'display' sample, that's about 500+ rounds and about 500*500/2
SendMessage() calls less now on my dev/test rig, taking noticeable time
to start the display application.
---
Issue was found due to the barrage of '(winmsg)' Windows Message debug
log lines zipping by in the monitor app when the sample was build in
Debug Mode. Only significant difference with the Release Build is those
debug lines being output, hence the performance gain is less, but still
measurable, in a Release build. When the machine is otherwise severely
loaded (UI render core maxing out), "measurable" becomes "obnoxiously
noticeable" again on Win10/64.
Closes#22049.
Extend the existing use of wxIcon in wxDataViewIconText,
wxDataViewCheckIconText, the corresponding renderers and
wxDataViewTreeCtrl to wxBitmapBundle.
As with the other classes, the existing setters have been preserved as
they remain almost entirely compatible with the existing code and the
return type of the existing getters was preserved, with new getters
being introduced for returning wxBitmapBundle only where they're really
required.
Update the sample to use wxBitmapBundle with its wxDataViewTreeCtrl.
Embed SVG data of the wx logo into the library itself to make it
available to all wx programs, including the samples. This is a bit
wasteful, but <12KiB is not really noticeable compared to the library
size.
Use wxTE_RICH2 for a control that we call EnableProofCheck() on, as
using this function without this style asserts in wxMSW.
This should have been done in 5ba2461fd1 (Switch to using GSpell for
wxTextCtrl proof checker in wxGTK, 2021-09-08).
In webview sample toolbar use wxBitmapBundles created from SVG files
instead of XPM bitmaps, as this results in much better appearance in
high DPI.
Closes#2642.
The year is now included in the copyright string used in the makefiles
and so they need to be regenerated every time the year changes (which
happens surprisingly frequently).
It would be better to define a single variable with the year number to
avoid having to do this in the future.
This sweeps under the carpet the regression which resulted in bitmaps
returned from wxArtProvider::GetBitmap() not looking the same since
starting to use wxBitmapBundle in AUI, but OTOH it just doesn't seem
possible to both preserve the compatibility and allow actually using
appropriate, not scaled, bitmaps in different resolutions.
The new code is as simple as the old version, follows the official
advice to use GetBitmapBundle() rather than GetBitmap(), and looks good
in high DPI, which should compensate for the behaviour change.
wxAuiToolBar::SetToolBitmapSize() doesn't do anything and never did ever
since it was added back in 1154f91b6a (added wxAuiToolBar, 2008-08-24),
so don't bother calling it, this just makes the sample code confusing as
no effect from passing different sizes to SetToolBitmapSize() can be
seen during run-time.
To enable fullscreen support with WKWebView private API which was
available since macOS 10.11 was used. Beginning with macOS 12.1 this
resulted in unpredictable layout issues inside the webview.
This reimplementation using java script and message handlers does only
use public API. This also makes the fullscreen message more controlable
as the webview does no longer put the containing window in fullscreen
mode without application code intervention. That also unifies macOS with
the way Edge sends this event in MSW.
Closes https://github.com/wxWidgets/wxWidgets/pull/2629
Using a const char* and a wxString in the two branches of the ternary
operator resulted in compile-time errors since the result type of the
conditional expression was ambiguous, so add explicit conversions to fix
it.
Closes https://github.com/wxWidgets/wxWidgets/pull/2634
See #19355.
It seems like this function will need to be used in every implementation
of EVT_LIST_COL_CLICK handler when using sorting, so it makes sense to
provide it in the library itself.
The old API seems unnecessarily complex, it is simpler to just let the
application call ShowSortIndicator() itself from its
wxEVT_LIST_COL_CLICK handler, which needs to be defined anyhow in order
to actually sort the items, rather than require it to enable sort
indicator, explicitly set it initially and then remember to not set it
any longer in response to the column clicks.
Also make RemoveSortIndicator() non-virtual and implement it simply as
ShowSortIndicator(-1) because this actually simplifies the code too.
The previously working code should continue to work, so keep the
original version now that it does work after the changes of the previous
commit.
Just mention in the comment that te data object can also be retrieved
directly.
Allow specifying multiple formats to be accepted when dragging data to
wxDataViewCtrl in the generic and Cocoa implementations.
Add wxDataViewCtrlBase::EnableDropTarget() overload taking an array of
wxDataFormats to support this at the API level.
Add new DoEnableDropTarget() used by both EnableDropTarget() overloads
and implement it in the generic and Cocoa ports. GTK implementation
still uses only a single format, as before.
Also refactor the Cocoa implementation: all operations using dragged
data are now handled by wxDropTarget and unnecessary DataViewPboardType
as removed.
Update the dataview sample to show the new functionality.
This fixes the wxGenericCalendarCtrl on wxGTK3 where the SpinCtrl is
much wider than on other platforms and should also ensure that the
control is always big enough in all locales under Mac.
Closes https://github.com/wxWidgets/wxWidgets/pull/2604Closes#11444.
Add an item with unspecified year and update the custom model GetValue()
to not return anything in this case to check, and confirm, that all
implementations handle this properly by simply not showing anything in
the cell in this case.
