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.
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.
This function can now be implemented relatively straightforwardly
(although it does require an extra check under Mac), so add it, as it
can be generally useful and we're also going to need it for our own
tests in the upcoming commit.
This finally seems better than always creating some kind of impl object,
even if the locale isn't supported at all and makes all ports behave
consistently, as previously CreateForLocale() only returned NULL in
wxOSX implementation if the locale was unrecognized, but now all ports
do this (at least when locale_t and related functions are available
under Unix).
Also stop returning bool from Use(), as this resulted in initializing
wxLocale with any non-default language to fail under Mac: just ignore
the error here, as we always did it until now, because there is nothing
we can do about it anyhow.
This required changing CompareStrings() to be a method of wxUILocale
object, rather than just as a static function, as we must only allocate
the locale_t object once, and not during each to this function, as this
could make it unusably slow when using it as a comparison function when
sorting a large list of strings.
This is also more efficient under Mac, where we can similarly allocate
NSLocale only once and even marginally more efficient under MSW, where
we don't have to construct the locale string during each call. And,
under all platforms, it also simplifies code by separating this function
implementation from the initialization of wxUILocaleImpl.
Also document that case-insensitive comparison is not available under
Unix and adjust the tests accordingly.
Creating such objects (without using them for the UI) is supported under
all platforms, so allow doing it.
Note that this is only supported under Unix systems when locale_t and
related functionality is available, but this should be the case just
about everywhere by now.
Add a test (or, rather, replace an existing test which was disabled by
default) checking that we can now get locale information about any
locale, not necessarily the currently used one.
Use the recommended name-based NLS API rather than legacy functions
taking LCID.
Preserve compatibility with Windows XP by keeping the old code for now,
but it will be removed after 3.2.0.
Add Use() virtual function which can be used if the newly created
wxUILocaleImpl object should be used as the default UI locale.
Currently Use() is always called after creating a new wxUILocaleImpl, so
adding a separate function just seems to complicate matters needlessly,
but this won't be the case any more soon, when wxUILocaleImpl could be
created for using them for other purposes than making them the default.
No real changes yet.
This function can be used for all GetInfo() items, so using it is
simpler than the code in the Unix version of wxLocale::GetInfo() which
uses either it or localeconv(), and there should be no real drawbacks to
using it nowadays as it should be available everywhere.
No real changes yet.
