Don't define operators for wx types in global scope.
This results in much better error messages when the compiler gives an
error about failing to resolve a call to some operator in user code
because it doesn't list all the wx-defined operators as candidates. In
practice, this cuts down error messages from 500 (!) lines to 2 with
gcc.
See #24190.
Still use the traditional dot file if it already exists, but prefer
using the new location otherwise, i.e. for the new program installation.
Add wxCONFIG_USE_HOME to allow forcing the use of the old location if
really necessary.
Also use the new style as default "old style" of MigrateLocalFile() so
that calling it even when using XDG layout in wxStandardPaths still
works as expected.
Sometimes it's useful to have some code used only if wxConfig is defined
as wxRegConfig or only if it is defined as wxFileConfig and testing for
these symbols is more clear than testing for the platform (and more
correct, considering that setting wxUSE_CONFIG_NATIVE to 0 may result in
wxFileConfig being used even under Windows).
Don't tell people to build all the samples and demos because this takes
time and some of them are badly outdated. Do tell them to build and run
the minimal one to check that things work as intended.
Also remove links to the wiki from wxOSX instructions, there is not much
useful from non-archaeological point of view there.
Don't say that the directory where the archives are unpacked shouldn't
contain anything else than include and lib directories, as it can/does
contain other files, such as wxwidgets.props.
Closes#24098.
Co-Authored-By: Bill Forster <billforsternz@gmail.com>
Fix wxBitmapBundle::FromSVG(), which renders incorrectly on GTK and add
wxHAS_PREMULTIPLIED_ALPHA to make the code dealing with alpha more clear
and correct.
See #24097.
It was incorrectly called wxAppConsole::YieldFor() but the function was
moved from wxAppConsole to wxEventLoopBase back in dde19c2180 (second
part of #10320: move wxApp event handling functions to wxEventLoopBase
(in particular move Yield() functions); add backward compatible
redirections to wxApp; update docs; remove global lists wxPendingEvents
and wxPendingEventsLocker, 2009-02-15).
Closes#24095.
Refactor wxImageList and convert it to use physical pixels and
add support for high DPI state images wxTreeCtrl using the new
wxImageList.
See #24000, #24033.
This seems to be the only way to fix using this class, which is
fundamentally incompatible with high DPI support, with bitmaps of
different logical but identical physical sizes.
By using physical size we ensure that the code chopping up the provided
bitmap in multiple images doesn't do it with the bitmap having the same
physical size but a different logical size from all the other bitmaps.
And, conceptually, logical size of the bitmaps in it really shouldn't
matter to the image list as it doesn't have a scaling factor and so
can't do anything useful with the logical size.
Moreover, we can't add wxImageList::SetScaleFactor() neither because
this class is, by design, supposed to be shareable between different
controls which may use different scale factors, so it doesn't make sense
to speak of the scale factor of the image list itself.
This undoes the changes made in the generic implementation back in
c374eefd34 (Fold wxOSX-specific wxImageList into generic version,
2018-10-30) and also eb52e86553 (Take into account scale factor of
images added to wxImageList, 2021-04-03).
Also update a couple of places where wxImageList is still used to use
physical sizes. Unfortunately some others can't be easily fixed, e.g.
global wxFileIconsTable would have to be completely rewritten.
Finally, add a unit test checking that things work as expected now:
previously the size of 24x24 bitmap in the image list containing
(scaled) 32x32 bitmaps would be 21x21 due to sub-bitmap extraction
kicking in.
Closes#23994.
It made sense to emphasize its use when this was the recommended way to
set up MSVS projects, but now the simplest (and hence recommended) way
to do it is using wxwidgets.props file, so make the manual setup
instructions more generic as they're most likely to be used with
non-MSVC compilers.
We had instructions for building wxWidgets with MinGW but not for
building the applications using wxWidgets, so add them too now in the
hope that it will be helpful to people who struggle to find the options
to use for building -- or at the very least to the people who have to
answer the questions about this, as they could now just point to these
instructions.
Change wxTreeCtrl style for a control used by wxGenericDirCtrl so that
wxGenericDirCtrl looks more like the folder view in File Explorer (but
still don't show expanders for root-level items).
Also update wxGenericDirCtrl screenshot in the docs.
See also 6caaf58 (Use more modern appearance for wxMSW wxTreeCtrl by
default, 2023-09-30).
Closes#23922.
This allows to suppress some or all GTK diagnostics even for the
programs not calling GTKSuppressDiagnostics() nor even
GTKAllowDiagnosticsControl() themselves.
Change wxTreeCtrl default style under wxMSW to make it look more
up-to-date by default: use twisting buttons and full-row highlight and
don't display connector lines.
Using wxTR_LINES_AT_ROOT together with wxTR_NO_LINES may look odd but it
is needed because without wxTR_LINES_AT_ROOT, the buttons would not be
displayed.
Also update wxTreeCtrl screenshot in the docs.
Closes#23844.
Make the wxString(std::string_view) constructor explicit.
Otherwise, when comparing a std::string_view with a const char *, the
cast to wxString will be considered as a candidate for the comparison,
ultimately causing an "ambiguous overload for 'operator=='" error.
For example, this sample only builds if the constructor is explicit:
#include <wx/string.h>
#include <string_view>
int main() {
std::string_view view = "abc";
const char *str = "abc";
return view == str;
}
However, making the constructor explicit will break assignment:
std::string_view view = "abc";
wxString s;
s = view; // Error: no match for "operator="
That we can fix by implementing operator=(std::string_view)
That, however, introduces another ambiguity:
std::string str = "abc";
wxString s;
s = str; // Ambiguous between s = wxString(str)
and s = std::string_view(str)
That we can fix by implementing operator=(std::string)
Finally, note that some rather obscure ambiguities remain, such as:
wxString s;
s = {"abc", 2}; // Ambiguous between s = wxString("abc", 2)
and s = std::string_view("abc", 2)
Avoiding them is not simple (https://cplusplus.github.io/LWG/issue2946)
and doesn't add much value.
Closes#23834.
Deprecate wxXmlResourceHandler::GetAnimation() function which returns
just a single animation and add a new GetAnimations() replacing it.
Use the new function in wxAnimationCtrl XRC handler to pass all the
animations defined in the XRC file to the control.
This reverts 5d630caabd (Make it enough to predefine only
wxUSE_DPI_AWARE_MANIFEST, 2023-08-23) and all the commits which tried to
fix the breakage caused by it.
While the original change had merit, it seems to be too difficult to fix
all our build systems to avoid embedding manifest when defining this in
the code, like samples/sample.rc does, so revert this change for now.
Maybe it can be reintroduced in the future after switching to some other
build system.
If this is predefined before including wx/msw/wx.rc, it clearly
indicates that wx manifest should be used, but this was _not_ the case
before as wxUSE_RC_MANIFEST could be predefined as 0 (which is the case
for MSVS, to avoid conflicting with the manifest embedded by it into the
executable by default).
Change this and do include the wx manifest if wxUSE_DPI_AWARE_MANIFEST
is defined.
This should help people who check out the repository without submodules.
It's a bit circular, as the target of the link links back to this page
itself, but doing anything else would require much deeper reorganization
that can't be done now.
Closes#23683.
It doesn't make sense to keep the old and almost never used alternative
wxClipboard implementation which has known fatal bugs (such as casts of
wxDataObject that could be wxDataObjectComposite to wxBitmapDataObject,
see #23564) when wxUSE_OLE is never going to be disabled anyhow.
Note that this means wxSetClipboardData() function doesn't exist at all
any longer when previously it was available in the wxUSE_OLE==0 builds.
As the official builds always used wxUSE_OLE==1, this doesn't look like
a huge loss, but if needed, we could add it back later and reimplement
it in terms of wxClipboard::SetData().
This function was added back in a047aff270 (Added wxBORDER_THEME,
wxWindow::GetDefaultBorderForControl(), wxWindow::CanApplyThemeBorder(),
2007-08-07) but seems to have been made completely unnecessary by
dc797d8e1b (More border rationalisation. GetDefaultBorder is now mostly
defined in base class files., 2007-11-13) soon afterwards and never did
anything other than returning wxBORDER_THEME, with no explanation as to
when it might be useful to override it not to do it.
It also doesn't seem to be really used anywhere outside wxWidgets and
has never been documented, so make it non-virtual and deprecate it to
avoid confusion and simplify things.
In the note about building wxWidgets with MinGW makefile and using
parallel build, explain that "-jN" option cannot be used when building
"setup_h" target.
Closes#23642.
Clarify that it is 1 by default in the documentation, instead of
implying that it's off by default and needs to be enabled.
Improve the description of this option in setup.h files.
And also document this compilation option in the summary page.
This symbol is similar to the existing wxNO_IMPLICIT_WXSTRING_ENCODING
and can be defined when building the application (as opposed to when
building the library) to disable implicit wxString conversions to
pointer types, i.e. char*, wchat_t* and void*.
This makes the just added wxUSE_CHAR_CONV_IN_WXSTRING library build
option unnecessary, so remove it.
