The primary documented way of using a .natvis, in the Microsoft
documentation linked to, is to add it to one's project, not to copy
it under %USERPROFILE%.
Closes#26452.
When available, acquire the name and release of the Linux
distribution and return it as wxGetOsDescription()'s output,
followed by the near equivalent of the traditional 'uname -srm' output.
The uname output, something like "Linux 6.19.0-5-generic x86_64",
is not the best description for a Linux system, since it leaves
up to the reader to figure out what kind of a system this actually
is.
The output changes significantly from what it was earlier, but
the output was never meant to be machine-readable, nor was it
consistent across different operating systems.
Closes#26231.
An introduction to lsb_release is unnecessary, and saying it is very
common on modern Linux distributions is an exaggeration, at least today.
And besides those, the details are not even accurate since
aef7df6 (Read Linux distribution info from os-release file, 2023-07-14)
(#23712), which made lsb_release the fallback method for obtaining
information.
Closes#26125.
This implementation was surrounded by #if 0 ever since it was added in
7c07201 (don't disable hidden windows in wxWindowDisabler, it's at best
useless, 2003-06-21).
Closes#25982.
Only wxDateTimeWorkDays::DoGetHolidaysInRange() did an early
exit when start > end, but surely no other overridden
DoGetHolidaysInRange() would want an invalid range either.
This enables fixing potential bugs in holiday calculations, as
well as adding new holidays, through updating dynamic libraries,
without recompiling the application using wxWidgets.
wxDateTimeChristianHolidays was tested with a wxDateTimeUSCatholicFeasts
already existing and taking precedence. I.e. the tests for Christmas in
ChristianHolidays actually tested (again) the USCatholicFeasts
implementation.
This reveals an off-by-one bug in wxDateTimeChristianHolidays::DoIsHoliday(),
which doesn't use the enum symbol for month, and declares Christmas to be
on the 25th day of the 13th month.
Further, this raises the question whether it is a bad idea to have the
authority implementations in a header. Fixing bugs like this would
require recompiling the application, instead of simply updating the
DLL/dylib.
TestTimeTicks() checks were skipped for test dates with gmticks == -1,
ensure that these tests really run by providing the expected ticks
values.
See #24442.
The assert, introduced in 408aef5 (as we cannot handle zero commands
properly, we have to warn, 2005-01-04) says that menuitem ID zero
does not work on Mac, yet empirically it seems to work just fine.
If it really doesn't work, then this assert should be present in
all other ports too, to help writing portable code.
Closes#25306.
Move determining compile-time GTK+/QT versions to wxAppTraits,
which is presumably the only reason why wxGetLibraryVersionInfo()
needed to be in core.
Revert "Move wxGetLibraryVersionInfo() to core from base."
This reverts commit 9aea251043.
Closes#25236.
Instead of outputting just "10.0", output e.g. "10.0.19045".
On Windows, at least, today the micro version has more significance than
it perhaps did 17 years ago when the code was added.
Closes#25175.
Not accepting them was an accidental regression introduced in #24957,
fix it by accepting any kind of characters in the wrapper functions and
not just "char[]".
This went unnoticed because there weren't any such calls in wx's own
tests or samples, so add some to the test suite to prevent similar
regressions in the future.
Closes#25063.
Avoid warnings about incompatible casts:
In file included from ../../tests/allheaders.cpp:369:
In file included from ../../tests/testprec.h:5:
In file included from ../../include/wx/evtloop.h:13:
../../include/wx/event.h:141:12: error: cast from 'void (wxEvtHandler::*)(wxFocusEvent &)' to 'wxEventFunction' (aka 'void (wxEvtHandler::*)(wxEvent &)') converts to incompatible function type [-Werror,-Wcast-function-type-mismatch]
141 | return reinterpret_cast<wxEventFunction>(func);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This warning was already suppressed on GCC; just do the same thing for
Clang also.
Closes#25064.
If a new wxNO_REQUIRE_LITERAL_MSGIDS is defined, redirect the
translation macros to wrapper functions that only accept string
literals. This is not enabled by default, because it would be a
backward-incompatible change (even though most incompatibilities
uncovered by it are likely to be bugs), but defining the new macro is
recommended because the arguments nearly always need to be string
literals.
While at present the arguments do not technically need to be string
literals, variables can easily introduce subtle bugs that are not
obvious to spot. The fact that xgettext only picks string literals
is easy to forget.
Consider the following code:
wxString itm("item");
_(itm);
wxGETTEXT_IN_CONTEXT("context_1", itm);
wxGETTEXT_IN_CONTEXT(itm, "item");
wxPLURAL(wxString::Format("%s", "singX"), "plurX", 1);
wxPLURAL("singY", wxString::Format("%s", "plurY"), 2);
wxGETTEXT_IN_CONTEXT_PLURAL("context_1", _("singZ"), "plurZ", 1);
All of these lines compile without warnings. However, only one string,
"singZ", is picked by xgettext, all others are silently ignored. Some
lines would work if accompanied by a proper wxTRANSLATE* call, but nested
calls (see the last line) to translation macros do not make sense in the
first place.
Closes#24957.
Replace most 'neither' words introduced after 2b0ee48ef7
(Fix double negatives used with 'neither', 2023-11-25)
with 'either'.
All changes are to comments only.
Closes#24999.
Placing wxTRANSLATE() within wxGetTranslation() was never its intended purpose,
and while possible, totally misses the point of what wxTRANSLATE() is sometimes
needed for.
Added in:
bf2d923 (...; use wxTRANSLATE instead of wxGetTranslation for the 'Bad luck...'
literal, 2009-01-16)
7256e9b (...; add some notes about the logic of the program, 2009-01-16)
Also, GNU gettext -- modern versions, at least -- do not look for _() by
default, so the comment about xgettext knowing of it is inaccurate.
085c26a (updated Japanese translation, minor changes to the code, 2003-03-29)
Today, mailing list is not the place to submit new translations.
Nobody needs to grab GNU gettext from a GNU mirror and compile it from
source in order to use it.
Trusting people to find the right way to achieve these goals without
explicit instructions in internat sample's readme.txt. (Instructions that
might once again get outdated unnoticed.)
Write xgettext's output to .pot, not .po. Initialize a .po properly,
instead of leaving it up to the translator to set all the header fields'
values.
When updating the translation, do not use xgettext for it, as it will
overwrite all the header fields with default values. Use msgmerge instead.
Do not mention wxstd.pot at all here; keep these instructions focused on
one thing.
Do not use -C for xgettext, nor stress how important it is, as it is
remarkably unimportant here. The source file's language is correctly
auto-guessed to be C++, by the file extension.
Use msgfmt with -c, which is important to ensure valid syntax.
The compilation fix in PR #24925, a47b560 (Fix
wxGETTEXT_IN_CONTEXT* with wxNO_IMPLICIT_WXSTRING_ENCODING,
2024-10-29) aimed for the wxNO_IMPLICIT_WXSTRING_ENCODING
case presumably also has the side effect of preventing
non-ASCII (non-English) msgids with wxGETTEXT_IN_CONTEXT_PLURAL,
also in the regular case when implicit encoding is permitted.
It is best to define wxGETTEXT_IN_CONTEXT_PLURAL separately for
both wxNO_IMPLICIT_WXSTRING_ENCODING and without it, similarly
to how wxGETTEXT_IN_CONTEXT is defined. For some reason it
was defined only once until now.
This commit reverts the definition of
wxGETTEXT_IN_CONTEXT_PLURAL for the regular case to what it
was before.
Closes#24944.
The purpose of WXINTL_NO_GETTEXT_MACRO is, as I understand it, to avoid
name clashes between _() and symbols with the same name introduced by
other libraries or compilers.
Although wxPLURAL has forever (15d0695 (added wxPLURAL() macro,
2005-06-01)) been conditionally defined, there is no similar need with it.
wxPLURAL has a longer name, and is wx-prefixed. The other, more recently
introduced translation macros are not conditionally defined, which makes
wxPLURAL inconsistent in this regard.
Closes#24943.
The call to wxGetTranslation() was ambiguous. Fix this by adding missing
wxASCII_STR() for all string literal arguments in wxGETTEXT_IN_CONTEXT
and wxGETTEXT_IN_CONTEXT_PLURAL, just as it is used in _().
Also test that all translation macros expand to compilable code
when wxNO_IMPLICIT_WXSTRING_ENCODING is enabled.
See #1312 and also #24916.
Closes#24925.
Checking for availability of 'warn_unused' using __has_cpp_attribute
evaluates to false with Clang, even when the attribute is actually
available. __has_attribute gives the correct result, so use it instead,
despite the aesthetic inconsistency with other checks.
See #24833.
Closes#24907.
Clang 19.1.0 on Fedora Rawhide fails to compile <wx/archive.h>
because m_rep's members are accessed as if m_rep was not a pointer,
but it is.
This is obviously wrong with any compiler, but apparently because
wxArchiveIterator is a template class, and its operator=() is
never called in tests, its brokenness went unnoticed.
Use the wxWARN_UNUSED attribute in wxString's definition. Compilers do not
typically warn about unused non-POD objects, but this attribute makes it
possible (on GCC and Clang).
Whether a warning is actually shown or not still depends on whether
the user has enabled warnings for unused variables in their compiler flags.
Also known as [[gnu::warn_unused]].
Use __has_attribute to check availability of the attribute. (Is available
on recent GCC and Clang versions, not available on MSVC.)
While wxString::operator!() is a documented alternative to .empty() since
25 years, using it in just a handful of places in the codebase is not
consistent.
!str is arguably not very readable either, because std::string does not
have such an operator, and neither does e.g. Qt's QString. People would
generally except ! in the context of any kind of strings to check for null
pointer (char*), or an optional with a missing value (std::optional).
MSVC claims to support dates up to 3000; what glibc, OSX, or other *nix
claim is unknown, but they shouldn't do any worse than our own code and
can do better.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
This is very essential, since otherwise GetTicks() would become
practically useless at Y2K38, i.e. less than 14 years from now.
Also remove redundant cast of TIME_T_FACTOR, which is already
long, and does not need to be explicitly cast to long.
For an unknown reason, the Gtk implementation only used to post a
wxEVT_NOTIFICATION_MESSAGE_DISMISSED event if the associacted reason
code was either 1 or 2. To be consistent with with MSW, post the
event regardless of what the reason was, potentially enabling the
event for reasons ByApp and Unknown.
On all platforms, except macOS, the reason why a notification was
dismissed is known. Specifically, it can be useful to distinguish whether
the notification closed because of a timeout, or a click by the user.
Shift-Ctrl-N was already taken when it was added for the font dialog in
9b25ed0 (Add an accelerator for the font dialog in the dialogs sample,
2022-04-16). Use Shift-Ctrl-J instead.
Closes#24324.
If the latest user notification shown was shown with
"Use persistent taskbar icon" toggled on, the application process
would never really exit after closing. So delete m_taskbarIcon
in destructor.
Closes#24316.
wxMSW could already be compiled for ARM with MSVC, but due to not
defining any ARCH_SUFFIX for ARM, makefile.vc used to place objectsi
and libraries to the same folder as x86 objects and libraries.
A completely different question is what kind of Windows runs on 32-bit
ARM, and whether one can run regular desktop apps on it.
This commit mimics what f69dbaa1 did for ARM64, and adapts it for ARM.
Closes#24222.
Replace most 'neither' words introduced after 66916c74a3 (Fix double
negatives used with 'neither' in docs and comments, 2022-08-15) with
'either'.
All changes are to comments only.
Closes#24090.
Similar items were added context in d85f0e311d (Use translation context
for standard OSX menu items, 2022-05-02) but some were missed back then.
The context primarily serves as a translator comment, informing that these
are indeed OSX menu item names, and not something else.
Also to match the established translations of OSX itself, for some
languages these may need to be translated using particular terminology
different than on other platforms.
See #23213.
Such functions modifying errno is undocumented, and may come
as a surprise to the caller. Consequently also a call to
wxString::Format() would modify errno.
For no obvious reason the generic calendar control used
a read-only wxComboBox until now.
While this is more or less identical to a wxChoice on MSW,
it is somewhat different on OSX and Gtk: Whereas a wxChoice
can be opened by clicking anywhere on it, a wxComboBox requires
clicking on the arrows on the right edge. A wxComboBox
allows selecting and copying the current value, but this is
probably not terribly useful in a calendar.
See #22853.
In many cases it should be 'either'.
No changes to actual code.
Complements #22723, which focused on API docs and comments in C++ code.
Co-authored-by: Ian McInerney <ian.s.mcinerney@ieee.org>
See #22798.
The context primarily serves as a translator comment, informing that these
are indeed OSX menu item names, and not something else.
Also to match the established translations of OSX itself, for some
languages these may need to be translated using particular terminology
different than on other platforms.
Just spell out "Quit Application" and "Hide Application" as is,
without string concatenation.
Translating individual words can be complicated with some languages.
This change affects the case when wxTheApp is NULL, which presumably
is quite rare.
Closes#22384.
It looks like wxGetTranslation() was not actually called for these strings
earlier, so do call it.
The context fulfills also the same purpose as TRANSLATORS: comments --
removing comments as redundant.
Many key names are short and commonly used words; e.g. "Delete", "Left",
"Right", "Pause", "Menu", "End".
It is not at all unlikely that such words could be used in a completely
different meaning elsewhere in the code. That is why this list of
keys should be assigned a context.
The context fulfills also the same purpose as TRANSLATORS: comments --
removing comments as redundant.
Accept the same kind of time zone specifiers that RFC822 timestamps
accept; most importantly the "+0200" style.
Added more tests, and changed the way tests compare dates:
Since some timestamps now specify a time zone, those need to be compared
as UTC to avoid the system's time zone affecting the tests. Others can
still be compared as local time, as before.
Out-of-bounds was already covered by the fact that the date is appended 32
zero-bytes in ParseRFC822Date() as a safety measure. But now the time zone
parsing section of the function no longer relies on those extra zeros
being present.
Added tests for RFC822 timestamps with military time zones, and more types
of truncated, invalid time zone specifiers.
Correction to the commit:
2153ffc (Test ParseRFC822Date() with truncated time zone specifiers,
2022-03-19)
The inputs failed as expected, but due to an unrelated reason (missing
comma).
Set the end iterator to the end of the actually parsed date, instead
of consuming any ultimately unparsed whitespace/delimiters possibly
following the date.
In other words, check that the unprocessed part of the input is what
we expected.
Also add some cases where a valid date or time is followed by something.
The intent of the implementation clearly is to allow parsing time first,
date second. But this failed, because a time such as "14:30:15" would
successfully parse as a date (as 14th of current month, current year).
Consequently an attempt is made to parse the actual date as time, which
fails, and therefore the whole ParseDateTime() fails.
Adding a failing test case for ensuring times cannot be parsed as dates
does not cause a failure, because partially yet successfully parsed inputs
get silently ignored (in both ParseDate and ParseDateTime tests). Fixing
both of these, too.
Closes#22203.
The RFC accepts 2-digit years, and it makes most sense to interpret
e.g. 95 as 1995. However, this is an incompatible change, as earlier
95 was literally decoded as 95 AD.
Years 00..29 are considered to mean 20xx; 30..99 means 19xx.
Closes#22196.
Lauri Nurmi
Lauri NurmiandVadim Zeitlin
