These file lists contained files that were not low level (meaning "used
by wxQt/Univ" in this context) at all and it doesn't make much sense to
think about Qt-based wxUniv port anyhow, so instead of painstakingly
separating them in low level part and the rest, just rename the
variables to be less confusing.
Only define it unconditionally for wxMSW and wxOSX, not wxGTK where we
need to test that the required versions of FontConfig and Pango Fc are
available.
Also do all wxUSE_PRIVATE_FONTS-related checks in the same place, to
make things more clear and avoid similar blunders in the future.
Handle this feature as all the other ones and provide a configure switch
and a setup.h option to disable it if necessary, as it may be desirable
to do it, especially under Linux, to avoid extra dependency on pangoft2
if this functionality is unnecessary.
This doesn't work correctly in Catch after reverting the commit that
broke compilation with MSVC 9, so we have to live with explicitly using
the values of the correct type.
ftp.wxwidgets.org seems to have gone, breaking the existing test (thanks
chris for all the fish...), so don't hardcode this URL in the test and,
without it, don't run the test by default any more and require
specifying a working FTP host (as well as an existing directory and a
file on it) when running it manually.
Rewrite the test using normal functions instead of Java-like structure
imposed by CppUnit to make it simple to skip it.
Unfortunately there is no reasonable way to implement this function for all
glibc versions as the information we need is stored in the private
_GOptionGroup struct whose layout has already changed once (in 2.44) and could
change again, so we can't rely on it.
We really need a g_option_group_get_entries() in glib itself, but the request
to add it at http://bugzilla.gnome.org/show_bug.cgi?id=431021 hasn't been
touched since 10 years, so it seems unlikely to happen.
See 99367a1530 (commitcomment-25789514)
There is no shrink_to_fit() in wxVector in this case.
Arguably, we shouldn't be building wxVector unit tests in STL build at
all as there is no point in testing the standard class, but OTOH it
could be useful for checking that the tests themselves are correct, so
keep them for now.
Output the maximal difference between the differing images pixels to
show just how far are they from each other, exactly. And show the image
file name as well, for convenience.
Also run all checks instead of stopping after the first failing one.
wxInvalidSize is a documented return value for wxDir::GetTotalSize(),
yet it was not available by including just wx/dir.h as it was declared
in wx/filename.h only.
Fix this by declaring it in wx/dir.h too.
Closes https://github.com/wxWidgets/wxWidgets/pull/609
When column resizing is finished, after HDN_ENDTRACK notification there is
also sent one (and last) HDN_ITEMCHANGING notification. We have to skip it
to prevent from sending EVT_HEADER_RESIZING after EVT_HEADER_END_RESIZE
because EVT_HEADER_END_RESIZE should be really the last one event
in the sequence of resizing events (like it's assumed in wxGrid).
Closes#16390.
Ever since the changes of 544c4a3bde
(almost 14 years ago), playing mono WAVs with wxSound completely failed
if setting the sound device to mono using SNDCTL_DSP_STEREO ioctl
failed. This doesn't look like a wise thing to do, so don't consider
this as a fatal failure, but just play mono as stereo (and even possibly
stereo as mono) instead.
This fixes the sound sample being broken out of the box on many (all?)
Linux systems.
The code was completely broken as it locked the mutex in only one thread
and then tried to unlock it in another one, which made no sense, didn't
protect against anything and resulted in errors and assert failures.
Fix this by locking and unlocking the mutex in both threads before
accessing shared data or playing sound.
Closes#17990.
It seems to have been replaced by wxSoundPlaybackStatus::m_playing a
long time ago but was still kept, resulting in confusion and always
returning false from IsPlaying() as it tested a wrong variable.
Fix this by removing this one completely and always using the other one
everywhere.
Also use this for wxArray::Shrink() implementation as it's more
efficient than the old swap-based implementation which requires an extra
memory allocation instead of really shrinking the existing one.
Using assign() with int (in fact, any integral type) should select the
(size_type count, const T& value) overload, but didn't, which was
incompatible with std::vector<>.
Fix this by adding the same tag-dispatching technique as used by the
real std::vector<> implementations themselves, except that we dispatch
on integer types because we can't be totally certain that
std::iterator_traits<> are specialized for whatever iterator-like object
could be used with wxVector.
Remove maximal reallocation size in wxArrayString too, as it was done
for wxVector a commit ago, and increase its size by 100% and not 50%
when it needs to grow.
There is no real reason to use different growth strategies in the two
classes and wxVector one seems to be better.
Call assign() instead of Add() in a loop: this is not only shorter, but
also ensures that reserve() is called before starting the loop and all
the required memory is allocated at once.
This dramatically pessimizes performance for large vector sizes and
doesn't actually save that much memory because all intermediate
allocations are still being used by the process, so follow stdlibc++
example and just double the allocated buffer size without limit.
Native wxMSW dialog split the provided message into the title and body
in Update(), but didn't do it for the initial message specified when
constructing the dialog, resulting in weird jumps, due to the font size
change between the body and title dialog elements, if the updated
message differed just slightly from the initial one.
Fix this and refactor the code to reuse the same function for doing this
splitting in both places.
Use TDM_UPDATE_ELEMENT_TEXT even for the initial update as this allows
to specify the message of roughly comparable (or greater) length than
the messages that will be subsequently used while the dialog is shown
and avoid size changes later, which is much more natural than having to
do it for the first call to Update().
No real changes, just don't lock a critical section for a short time
only to lock it again almost immediately after unlocking -- just combine
both blocks for which it is locked into one, there is no reason to
release it for TASKDIALOGCONFIG and wxMSWTaskDialogConfig initialization
which are both trivial operations not involving any callbacks.
Unfortunately it doesn't seem possible to prevent the native MSW dialog
from changing its size in both upper and lower direction vertically, so
at least mention this in the documentation and mention a possible
workaround of manually adjusting the text to always have the same number
of lines.
