Don't leave m_useMask and m_scaleFactor uninitialized -- even if this
probably doesn't matter, call Create() to make sure they have
well-defined values for the default-constructed objects.
The existing variants returning wxBitmap are insufficient for non-MSW
ports where the toolbar bitmap size is unavailable otherwise, as
GetToolBitmapSize() value doesn't really correspond to it (which is a
problem on its own, but there is not much that can be done about it by
now).
Having these functions allows to retrieve the actually used bitmap size
by using wxBitmapBundle::GetDefaultSize().
Minimal changes to the code to allow using bigger bitmaps from
wxBitmapBundle in high DPI instead of having to create individual
bitmaps with scale factor greater than 1.
Notice that this is not actually used anywhere in wxGTK yet, but will be
soon.
Document which pointers can, and can't, be null and when exactly is the
stored bitmap valid, as this is far from being immediately obvious.
No real changes.
Pass wxSize by const reference instead of "const" value.
Note that passing wxSize by value might be not such a bad thing,
actually, but we use const reference for it everywhere else, so do it
here as well for consistency (and the original intention was to do it
like this, missing "&" was just a typo subsequently propagated through
copy-pasting).
No real changes.
Passing non-const data is inconvenient and error-prone, as data can't be
used again after it was modified by Nano SVG, which resulted in the
button using SVG bitmap not working any longer in the toolbar sample
after recreating the toolbar.
So make it easier to do the right thing, while still keeping the
overload taking non-const data for the situations when avoiding an extra
copy is worth it.
Add nanosvg submodule and use it in the generic implementation of this
function.
This is incomplete yet and, notably, doesn't cache the rasterized
images, but already shows that using SVG images works (at least in the
toolbar sample).
This first version provides only a generic implementation of
wxBitmapBundle using a collection of bitmaps and only supports using it
in wxToolBar in wxMSW and wxGTK.
More methods of creating wxBitmapBundle will be provided later and more
functions taking wxBitmap will be changed to take wxBitmapBundle later
too and, of course, all the other ports will be updated to use the new
API too.
wxObjectDataPtr::operator=() didn't handle self-assignment correctly,
i.e. could delete the object when doing "x = x".
Fix this by incrementing the reference count before decrementing it on
possibly the same object to ensure that it never reaches 0.
Define a single function and use it in both wxArtProvider and (the
generic implementation of) wxSearchCtrl instead of repeating the same
code elsewhere.
Note that another, but slightly different, version of RescaleBitmap()
still remains in wxPropertyGrid.
Deprecate undocumented wxArtProvider::RescaleBitmap() which is
completely useless now.
No real changes, this is just a refactoring.
Unlike the existing wxHAS_IMAGES_IN_RESOURCES constant defined only
under MSW, the new one is also defined under Mac and could be defined
for the other platforms/ports later (e.g. wxQt could probably support it
too).
It's unfortunate that two very similar constants are needed, but it
doesn't seem wise to change the meaning of the existing constant, as
this would change how the commonly used wxICON() and wxBITMAP() macros
behave and would break all our own samples that use them for their frame
icon but don't embed this icon into the bundle resources under Mac.
Do change the toolbar sample to use the new constant however, as this
one does include the bitmaps it uses in its bundle under Mac.
OpenVMS build was broken by 303d899cc0 (Make STL-based wxList more
compatible with the default one, 2021-09-02), try to blindly fix it by
casting the element to the same type it had had before.
Some existing code relies on wxEVT_TEXT being defined after including
just wx/combobox.h too, so just keep this formally unnecessary but by
now impossible to remove #include removed in d3eafa4d18 (Fix compilation
of wxFormBuilder-generated code using wxTE_XXX, 2021-07-14).
See #14132.
Closes#19264.
When one inserts one big line to a wxRichTextCtrl that is too long (say 300k words of average size 9), then wxRichTextCtrl could freeze for a few seconds. It could also freeze again when the control is resized (such that word wrapping is triggered again).
Problem: `wxRichTextParagraph::AllocateLine(int pos)` can be called many times. Each call triggers `m_cachedLines.Item(pos)`, which traverses the linked list. As a result we get quadratic time complexity.
In this commit, we improve the function by also caching the lines in a vector, which supports random access in O(1) time.
This comes at the price of breaking compatibility and returning
"\\share" rather than just "share" from wxFileName::GetVolume() for the
UNC paths. This breakage seems justified because it is required in order
to allow application code to distinguish between paths "x:\foo" and
"\\x\foo", which was previously impossible as GetVolume() returned just
"x" in both cases.
Document this change, adjust the existing checks for the new GetVolume()
semantics and add a new test which passes now, but didn't pass before.
Closes#19255.
This commit is best viewed ignoring whitespace-only changes.
Replace the workaround introduced as a "temporary fix to avoid breaking
backwards compatibility in 2.8" back in 9e1c7236e0 (don't treat foo in
c:\\foo\bar as network share, 2006-12-17) with a better solution
proposed in the comment in that commit, i.e. don't even try to extract
the volume from the path if we already have the volume separately.
This commit is best viewed ignoring whitespace-only changes.
Add wxComboCtrl::SetMainControl() which can be used to use some other
window instead of the default wxTextCtrl as the main window of the
combo control.
Update the sample and the documentation to show the new function.
Fix crash introduced by 8e8a68c1b (Move code accessing bitmaps to
wxRibbonButtonBarButtonBase too, 2020-02-07) which start using
GetAncestorRibbonBar() in wxRibbonButtonBar code, without taking into
account that we may have no ribbon bar ancestor when the button bar is
shown in a popup frame, as it happens when there is not enough space to
show it fully in the main window itself.
Remember the ribbon bar in a member variable, relying on the fact that
we must have it in our parent chain when constructed, and just use it
later to avoid this.
Closes#19249.
There doesn't seem to be any reason to disallow copying these objects
and because they only have const methods, we can use reference counting
for them without bothering with copy-on-write, so it's simple to
implement.
This static function parses a subset of the language tags described in
BCP 47 (see https://www.rfc-editor.org/rfc/bcp/bcp47.txt).
Use the tag, as specified by this function, rather than the locale
identifiers components under MSW, where this should allow us to use even
locales that can't be described using just language-script-region.
We don't use empty wxLocaleIdent as default user locale and it doesn't
make much sense to do it, as the default locale is already accessible
via wxUILocale::GetDefault().
No real changes, just don't make all wxLocaleIdent setters inline, this
is not necessary as none of these methods are performance-critical.
This commit is best viewed with --color-moved git option.
No real changes, just move this class declaration as it seems more
logical to have it in the same header with wxUILocale which is the only
place where it's used.
This commit is best viewed with --color-moved git option.
Just return NULL from this (wxOSX private, in spite of not using a
port-specific prefix) method.
This fixes crash in wxButton::SetBitmapXXX(wxNullBitmap), as shown by
the new test case which used to crash but doesn't do it any longer.
Closes#19257.
This is done to fix the build error in STL builds after the previous
commit, as using Find() or DeleteObject() with a pointer of the "base
type" worked when using wxWindowList in the default build, but not in
the STL build, so this commit avoids this mismatch by allowing to use a
base class pointer where it is safe to do so, i.e. where it can be done
without a downcast, as there doesn't seem to be any reason to have this
difference between the builds in this case.
Note that there is still a difference between Append() and Insert()
methods which (correctly) require the pointer of right type in STL build
but still accept a pointer of the base type in the default build for
compatibility reasons.
In particular, this means that one of the casts removed in the last
commit from wxWindowBase code needs to be restored, as Append() still
requires a wxWindow and not just a wxWindowBase.
Unlike MSW and macOS, creating wxUILocale for e.g. "en" doesn't
necessarily succeed under Linux even if "en_US" is available, so try to
find a working language+region combination if just language doesn't
work.
This requires access to the languages database, so add a private
wxGetLanguageInfos() to avoid having to depend on wxLocale just for
this.
There is no reason to use the macro-based classes for this array as
there are no compatibility constraints here, so use a simple vector
instead.
Note that we need an extra boolean variable now that we don't use a
pointer because we can't just check whether the vector is empty, as this
would return in infinite recursion when InitLanguagesDB() calls
AddLanguage() which, in turn, calls CreateLanguagesDB().
This is required for wxLocale compatibility, as using wxLANGUAGE_ENGLISH
is supposed to be the same as using "C" locale (even if it isn't,
really) at wxLocale level.
