Put linker flags determined by configure after -L$(LIBDIRNAME) option
pointing to the directory containing the libraries being built, to
ensure that we link with these libraries rather than any wx libraries
globally installed in the system, as could be the case since the changes
of ec091c9f2b (Don't override CFLAGS etc in configure-generated
makefile, 2020-02-02).
See #18729.
This has the disadvantage of not using the same accelerators in
different wxWidgets builds, but the advantage of appearing logical to a
casual user when running the sample, while having "0, 1, 3, 4" sequence
was surprising.
Alternatively, we could always add all menu items, but disable the ones
that are not available in the current build. It could be surprising to
see "GDI+" under non-MSW systems too though.
Make "Use default wxGraphicsContext" part of the renderer selection
radio group and put it in correct order, as having "1, 0, 3, 4"
accelerators order in the menu was really surprising.
Remove wxEVT_UPDATE_UI handlers as they complicated things in the sample
code (which is supposed to be simple, after all) without much benefit
and arguably even added to the confusion during run-time as menu items
could both be manually selected and checked automatically.
CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS are supposed to be under
user-control and putting configure-determined options in them broke
something as simple as running "make CXXFLAGS=-Wno-some-extra-warning"
because this overrode the CXXFLAGS set by configure and required for
build.
Improve this by using WX_*FLAGS in the generated makefile and leaving
the user-controlled FLAGS alone. This is still not ideal as running
"configure CFLAGS=-DFOO" and then "make CFLAGS=-DBAR" will define both
FOO and BAR, as configure copies CFLAGS to WX_CFLAGS, and so setting it
on make command line won't override it, as it should, but this should be
a much more rare and also much less severe problem, so we should be able
to live with it for now.
Normally this commit shouldn't result in any user-visible changes, i.e.
it shouldn't break any previously working scenarios and only make some
previously broken ones work.
This adds a demonstration of drawing with affine 2D transformation applied
to wxDC. Transformation paramaters (translation, scale, rotation angle)
can be set/reset with new menu "Transformation".
Done by running misc/scripts/inc_release, manually updating version.bkl,
rebaking and rerunning autoconf.
Also a header for the next version to the change log.
Provide a way to retrieve the name of the current system appearance
(mostly for diagnostic purposes) and check if it uses predominantly dark
colours.
Currently this class has a non-trivial (but still very simple)
implementation under macOS only and simply checks whether the default
text colour is brighter than the default background colour under the
other platforms, but other platform-specific implementations could be
added later.
Also update the drawing sample "system colours" page to show the system
appearance as well.
Add the handler earlier, as creating the handler main frame uses
wxArtProvider::GetBitmap() which can add the PNG handler on some
platforms (e.g. macOS, when using wxTangoArtProvider), so calling
wxImage::AddHandler() again after creating the frame could result in a
debug error message about adding the same handler twice.
Pass wxStrings directly to wxString::Format("%s") and similar
pseudo-vararg functions, there is no need for c_str() there since
wxWidgets 2.9.
Closes https://github.com/wxWidgets/wxWidgets/pull/1009
The use of wxS() is an optimization which can be used to avoid an
implicit conversion from narrow to wide strings, but such optimizations
are not really needed in the samples and just make their code less
readable, so remove them.
Closes https://github.com/wxWidgets/wxWidgets/pull/956
Complete support for fractional point sizes and font weights other than
light/bold.
Also harmonize wxFont API and implementation among all ports (fixing
compilation of those of them that were broken by recent changes).
See https://github.com/wxWidgets/wxWidgets/pull/919
This is a preliminary ARM64 platform support for wxWidgets at "it
compiles" stage. This will allow building and testing wxWidgets based
apps for oncoming Windows 10 ARM64.
Requirements:
- Visual Studio 2017 Update 4 or later with Visual C++ compilers and
libraries for ARM64 component installed
Building:
1. Open command prompt.
2. Change directory to build\msw subfolder.
3. Run "C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Auxiliary\Build\vcvarsamd64_arm64.bat" once.
4. Use `nmake TARGET_CPU=ARM64 ...` to build required flavor of wxWidget
libraries.
Notes:
1. Building of *.sln/*.vcxproj files does not support ARM64 yet. This
requires to hardcode Windows SDK to 10.0.15063.0 or later in
*.vcxproj files, which would render them non-compilable in older
Visual Studio versions. Microsoft is aware of this issue and is
planning a fix in the next version of Visual Studio.
2. wxmsw31ud_gl.dll does not build yet. Awaiting Microsoft to deliver
missing opengl32.lib for ARM64. Please, specify USE_OPENGL=0.
Closes https://github.com/wxWidgets/wxWidgets/pull/923
When using an out of source build, the files are not in the default wxWidgets directories.
Also search in the current directory, parent directory and sample sub-directories.
Closes https://trac.wxwidgets.org/ticket/18118
This undocumented "private" class was used for various windows UxTheme
functions which are available since WinXP. As wxWidgets 3.1 is XP+ it
does not make sense anymore to load the theme functions dynamically.
Advanced gradients are drawn using wxGraphicsContext and hence bounding box for underlying wxDC is not updated automatically. We need to update bounding box with extents of all used graphics paths.
Determine actual size of drawing area and use it (instead of virtual size of the window) as a dimension of the images to be saved. Thanks to this clipping, produced images contain only results of drawing operations and not lot of empty background space.
This library is now required when wxUSE_ACCESSIBILITY==1, but was only linked,
using a compiler-specific pragma, when using MSVC resulting in link errors
with gcc.
Fix this by adding the library to the bakefile for non-MSVC compilers and
rebaking.
