We currently don't use these files in the existing builds.
It might be a good idea to add another GitHub Action workflow checking
the message catalogs compilation that would be executed _only_ for the
changes to them, but this can/will be done later.
This internal function will be useful to check if the modules are
already initialized, i.e. if the library is in the "steady state"
between the end of the initialization and the beginning of the cleanup
phases.
Simply use wxVector instead, this shouldn't be less efficient (we rarely
remove the modules from the list and iterating over a vector should
actually be faster, as well as consuming less memory), but it avoids
ugly macros, is simpler to use and to debug and will be trivial to
replace with std::vector<> in the future.
No real changes, this is just pure cleanup.
In native OS X apps, focus ring is not shown around NSTableView controls
(focus is indicated differently, with selection's color).
See eece498 for the same fix in wxDataViewCtrl.
This adds a yet another conversion function, which is not ideal, but
still better than having to write ToStdString(wxConvUTF8) every time for
losslessly converting wxString to std::string: not only this is too
long, but it's also too easy to forget to specify wxConvUTF8, resulting
in data loss when using non-UTF-8 locale.
The simple test added in 59a8f26b01 (Add a unit test for wxWebRequest
query using URL parameters, 2021-03-06) worked when using httpbin.org,
but not when running httpbin locally, as it doesn't pretty-print JSON by
default.
Skip optional whitespace to make it work in both cases.
Not doing it, i.e. creating the window inside the static box as its
siblings, rather than children, may appear to work, but actually doesn't
always do it, for example the windows are not shown correctly when using
RTL locale.
Closes#19086.
For generic wx{Dir|File}PickerCtrl with text field the picker button
should be as high as the associated text field also when
wx{FLP|DIRP}_SMALL flag is set.
Closes#19087.
Avoid the need for ugly WX_NO_LOCALE_SUPPORT macro at the cost of a
couple of extra #ifs, which seems to be a worthy trade-off.
This also allows making the code calling setlocale("") for the default
language platform-independent.
No real changes.
Even if we do know about the system language, it's still better to let
OS/CRT handle it, as we may not know enough about it. E.g. "system
language" may actually be a mix of the different languages and formats
and we don't handle this case at all, while OS/CRT do just fine.
We must use GetUserDefaultUILanguage() and not GetUserDefaultLCID().
Although still not ideal, this is much better when the UI language and
the locale differ: when everything is in some language, it's better to
use this language and wrong date/number format than use correct
date/number format but a wrong language.
See #11594.
AppVeyor CI builds for Microsoft Windows only. Therefore, do not start builds
for changes made only in dfb, gtk, gtk1, motif, unix, and x11 folders.
Additionally, do not start the builds when only an *.md file in the root
folder changes.
Lastly, ignore all changes in the demos folder: Demos are not built by AppVeyor at all.
Check if the path is at least two characters long before accessing its
second character.
Add test cases for wxIsAbsolutePath() on MS Windows.
Closes https://github.com/wxWidgets/wxWidgets/pull/2262
X11 headers and libraries are only required if we're actually using X11
which may not be the case.
This allows to build wxGTK on the systems using Wayland-only GTK.
