Fix the build with -std=c++11 (instead of -std=gnu++11) by providing even
more declarations for the functions wrongly excluded from MinGW headers in
"strict ANSI" mode ourselves.
EditorConfig seems to be supported by more and more editors/IDEs, including
even the upcoming MSVS 2017, so it seems useful to provide its config file.
Combined patch with the following changes:
- Don't add wxGLAttributes::Defaults() when the attributes-list is NULL.
- Add display default attributes used in wx versions before 3.1 when the
attributes-list is NULL. These attributes are different for each platform.
- Fix wxMSW PixelFormatDescriptor initialization.
- Don't set color buffers when RGBA() is used.
- Fix setting colour sizes in OS X and a few other fixes.
- Make documentation more clear about these subjects.
Closes#17425.
Asserting before dereferencing a null pointer (in BuildBranch(), called
immediately after the asserts in question) is useless, as usual. Use wxCHECK
to complain and avoid crashing instead.
Closes#17776.
These classes only have inline methods and so don't need to be exported in the
first place and, moreover, doing it results in link problems where these
templates are instantiated for a type not used inside the library itself.
Closes#17777.
It only accepts std::vector<wxString>, not std::vector<T> for any type
convertible to wxString as both the documentation and the code misleadingly
claimed.
Due to a bug in MinGW (see https://sourceforge.net/p/mingw/bugs/2322/),
_stricmp() and _strnicmp() declarations are not visible when compiling without
optimizations. Work around this by declaring them ourselves.
See #17762.
Set WINVER/_WIN32_WINNT ourselves before letting MinGW to set them to very low
values corresponding to Windows 2000 on its own and preventing our code from
seeing any later additions to the Windows API, such as AttachConsole()
function used in src/msw/app.cpp.
Closes#17677.
Generic wxDataViewCtrl's EnsureVisible() previously only ensured that at
least some part of the item (even if just 1px of it) was visible,
instead of being fully shown.
wxToolBar::Realize() code for handling bitmaps with alpha channel was
incorrectly blending them with the toolbar’s background color, resulting
in much lighter appearance and broken antialiasing.
Fix it by clearing the composite bitmap to be initially transparent if
bitmaps with alpha channel are used. Doing so uncovered another bug in
how the composite RGBA bitmap was passed to native toolbar control, so
fix that as well.
Use wxMacConvertNewlines13To10(), not wxMacConvertNewlines10To13() when
copying content from native pasteboard. Perform this conversion not only
for 8bit text, but for UTF-16 one (which is the one actually used on
modern OS X versions) as well.
Emit wxEVT_TEXT_{COPY,CUT,PASTE} from NSTextView methods, calling native
implementation if not handled. NSTextField-based wxTextCtrl is not
supported, because it doesn't have the copy:/cut:/paste: methods.
Don't call makeFirstResponder:nil from windowDidResignKey: because it's
not a native behavior and subtly breaks some things (e.g. paste managers
or keyboard switched under some settings).
This was done to provide the illusion of Windows-like focus behavior
when a TLW is deactivated. macOS separates the concept of active ("key")
window and focus ("first responder") within it and it's possible and
normal to have the latter assigned even in inactive (non-key) windows.
wxOSX reset the responder to trigger wxEVT_KILL_FOCUS.
Instead, keep the first responder untouched and only run wx-side code to
handle focus lost as well as focus set in windowDidBecomeKey: This would
preserve behavior compatibility with other ports, while also playing
nice with macOS.
Improve the logic for determining whether the statusbar should be
renderer as for active/key window or a background one.
wxTopLevelWindow::IsActive() is not a sufficient test because it returns
false in some situations when the statusbar need to appear as active
(another floating window) and also didn't account for window-modal
sheets (which don't change statusbar appearance either).
Legacy API cairo_win32_surface_create() can create only 24 bpp RGB surfaces but new API cairo_win32_surface_create_with_format() introduced in 1.15.4 supports creating also 32 bpp ARGB surfaces.
So, this new API can be used to create ARGB surface directly from ARGB bitmap (HDC), superseding current implementation based on the access to the bitmap data with cairo_image_surface_create_for_data().
Unfortunately, 0RGB bitmaps are not supported by cairo_win32_surface_create_with_format() and for such bitmaps surface has to be still created from bitmap data.
VC++ compilers (at least up to VS 2015) seem to generate incorrect code for the dithering code taken from libjpeg (pass2_fs_dither() function), where it is known to create problems too.
Refactor the code to avoid invalid optimization in this function and turn optimization on.
Closes#17764.
When you compile wxWidgets with base64 support disabled, then
wxConfigBase does not declare DoReadBinary and DoWriteBinary.
Add a guard to wxRegConfig, so wxOVERRIDE won't cause an error.
Don't use "$4" inside m4 comment, as autoconf 2.69 somehow completely mangles
the generated configure when the 4th argument is indeed specified: we end up
with a part of this comment in the generated file.
Improve Travis CI build script: make build commands easier to read and modify
in .travis.yml and make their output in Travis logs more readable too.
Closes https://github.com/wxWidgets/wxWidgets/pull/388
The minimal sample had been already built as part of "make samples", so clean
it before rebuilding it using the installed library version, otherwise we
never do anything in this step.
There is no need to specify it explicitly any more and it seems to confuse
make because of an apparent problem with (insufficient?) quoting in Mac
builds.
Using a single long command was always inconvenient and started displaying the
build results strangely since starting to build the samples conditionally in
62d2f4e5f5, so try using multiple commands with
"set -e" to ensure that we abort the build as soon as possible.
When compiling wxWidgets with MinGW64, CHAR_WIDTH can be already defined as a
macro, avoid clashing with it by renaming our variable with the same name.
Closes https://github.com/wxWidgets/wxWidgets/pull/383
Add wxGraphicsContext::CreateFromNativeHDC() and wxGraphicsRenderer::
CreateContextFromNativeHDC() to allow creation not only from native
renderer object, but also from HDC, which is something universally
supported by win32 implementations.
Fix ClearColumns() to release associations between m_OutlineView and
native Cocoa control when re-creating the latter. Previously it only
created a new association, but left the old one with no-deleted native
control in the map.
Fixes#17485.
The changes in 1.2.9 (1.2.10 is just a bug fix release) affecting the use of
zlib in wxWidgets are:
- Improve compress() and uncompress() to support large lengths
- Fix bug when level 0 used with Z_HUFFMAN or Z_RLE
- Fix bugs in creating a very large gzip header
- Dramatically speed up deflation for level 0 (storing)
Closes https://github.com/wxWidgets/wxWidgets/pull/380
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.
