This commit improves the best locale match algorithm by prioritizing
closer matches and add many new tests verifying that this works as
expected.
In order to do this, new information had to be added to the language
database, which was extended with it and updated to use the latest
Unicode CLDR data and latest Windows 11 locale list.
Further, add a set of scripts for maintaining the language database up
to date and a GitHub workflow `genlangdb.yml` which can be run manually
to regenerate the wxWidgets language-related source and header files
from the underlying Windows and Unicode data. It produces 2 artifacts:
- wxLanguageDatabaseDist.zip allows to easily update the
language-related files in the wxWidgets repository by simply copying
all files.
- the normal workflow log and wxLanguageDatabaseLog.zip allow to check
all temporary files of the regeneration process and to detect
potential issues, before the language-related files are actually
replaced by the new ones.
Finally, fix wxUILocaleImplName::GetPreferredUILanguages: Under Windows
10 and above the Windows API function ::GetUserPreferredUILanguages()
returns only the primary UI language plus US English. Additional
preferred UI languages installed by the user are ignored, so instead of
using this function read the list of user preferred languages from the
Windows registry.
Closes#24855.
Work around the incorrect behavior of the native control, which causes
the buttons for expanding and collapsing to be displayed too small in
a wxTreeCtrl not using images at high DPI.
Closes#24640.
Closes#24941.
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.
Changes of 4f9186f1a1 (Increase usable scrolling range in wxMSW by a
factor of 10,000, 2022-04-30) broke device origin handling if axis had
non-default direction because we didn't account for their signs at all.
Just do it now by interpreting the origin correctly depending on
direction.
See #24938.
Closes#24198.
Based on the behavior of WIN32 LoadFile(), and the gdk-pixbuf BMP loader source
code, the alpha values are ignored unless the compression method is BI_BITFIELDS.
See #10915, #24219
Fix the change done in f89cbe6eab (wxQt: translate QPainter of
wxClientDC into window client area., 2024-10-28) to set up clipping
correctly.
See #24921.
Fix multiple problems with GTK mouse events:
- Avoid phantom release events after dismissing modal dialog (#24931).
- Do send enter/leave events for window-less controls in wxGTK (#24932).
- Fix coordinates in click events sent to window with capture (#24933).
Returning negative size, due to subtracting tool/status bar size from
it, was unexpected, so return empty, i.e. (0,0), size when the window is
iconized instead, as documented.
Because we don't have the correct client size when the window is
minimized (at least in wxMSW), postpone the actual update until the
window is restored, as we don't really need to do it until then anyhow.
Closes#24930.
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.
First of all, ensure that the press and release events do go to the
window with the capture, which may not have been the case at all when
the capturing window didn't have a corresponding GDK window, e.g. when
capturing mouse in wxStaticText-derived class.
And also adjust the coordinates to be correct for the captured window to
ensure that the window receives the expected events.
Send events about entering/leaving windows such as wxStaticText, which
don't have their own window at GTK level, and so don't get the
corresponding signals from GTK -- but we can still synthesize these
events if we detect mouse motion in another window.
This commit is best viewed with Git --color-moved option.
Closes#11848.
This commit fixes a long-standing problem with receiving "phantom"
events after dismissing a modal dialog shown from an event handler which
can be illustrated using the following example:
--------------------------------- >8 --------------------------------------
#include <wx/app.h>
#include <wx/button.h>
#include <wx/dialog.h>
#include <wx/frame.h>
#include <wx/msgdlg.h>
#include <wx/sizer.h>
#include <wx/stattext.h>
class TestApp : public wxApp {
public:
bool OnInit() override {
auto f = new wxFrame(nullptr, wxID_ANY, "wx Test");
auto b = new wxButton(f, wxID_ANY, "Dialog");
b->Bind(wxEVT_BUTTON, [f](wxCommandEvent&) {
wxDialog dlg(f, wxID_ANY, "Dialog");
dlg.SetSizerAndFit(dlg.CreateStdDialogButtonSizer(wxOK));
dlg.ShowModal();
});
f->Bind(wxEVT_LEFT_UP, [f](wxMouseEvent&) {
wxMessageBox("Got left up", "wx Test", wxOK | wxICON_INFORMATION, f);
});
auto* const sizer = new wxGridSizer(1);
sizer->Add(b, wxSizerFlags().Center());
f->SetSizer(sizer);
f->Show();
return true;
}
};
wxIMPLEMENT_APP(TestApp);
--------------------------------- >8 --------------------------------------
Showing the dialog by clicking the button and then dismissing it by
clicking the button in the dialog resulted in the message box coming up.
This was due to the fact that the existing code preventing GTK from
propagating key and mouse events upwards the window parent chain based
on using the global gs_lastEvent variable didn't work if an event
handler dispatched any events from inside it, e.g. by showing a modal
dialog which ran its own nested event loop: the global variable was
overwritten by the event handling in it and, after dismissing the dialog
and returning to GTK, our handler was called again for the parent window
with the same event that we had already seen, but we didn't ignore it
any more because gs_lastEvent had been changed in the meanwhile.
Fix this by replacing the global variable with a wxEventLoop member
variable and using the currently active wxEventLoop for storing the
"last event", as it ensures that the original event is not overwritten
by event dispatching in the nested event loop.
Note that it would be tempting to achieve the same effect in a much
simpler way by connecting "after" signal handlers for all the signals
that we want to prevent from bubbling up without affecting their default
handling and this actually works fine for all of them -- except the "key
press" one, as it needs to reach the TLW parent in order to trigger the
calls to gtk_window_propagate_key_event() and gtk_window_activate_key()
there and it seems tricky to call these functions manually without
running into infinite recursion. It would be nice if we could do this,
as this would also make using our custom event source (see commit
d0406f4606 (Fix handling of identical consecutive key events,
2014-08-15) and #15802) unnecessary, but for now use this less intrusive
fix.
Get rid of an ugly macro and also simplify things: we don't need
per-function static "eventPrev", as GTK event propagation never
interleaves the events of different types, so we can just have a single
global storing the last event for checking if we had already seen it or
not.
This reverts 42fdb98f74 (Don't prevent the other button release handlers
from running in wxGTK., 2014-09-27) because it doesn't seem necessary
any more: the original test case from #16055 which this commit was done
to fix works after reverting it and the modified test case from the same
issue doesn't crash any more neither. And, finally, wxTR_EDIT_LABELS
still works too (see #16573).
So follow the usual rule and do stop GTK signal handling if the event
was processed.
Don't crash in this function if it ever happens to be passed a null
pointer again (see the fix in the parent commit) and document that it
takes a non-null pointer.
Since the recent 27fe76fcbf (Fix wxPropGrid editor appearance after DPI
change, 2024-10-20) creating wxPropertyGrid in wxGTK immediately crashed
if there was no selection in it.
Check that we have a non-null selected property before calling
RefreshProperty() with it to avoid this.
See #24898.
Remove some remnants of the code resetting m_actionHintRect which became
unnecessary many years ago and don't use a temporary variable when we
can just assign to m_actionHintRect itself directly instead.
No real changes.
Offset the rectangle correctly: doing it before calling ClientToScreen()
didn't work because it doesn't seem to handle negative coordinates, so
convert client (0, 0) to screen coordinates first and then compensate
(which requires using the negative offset) for the adjustment already
done in wxClientDC.
We didn't use GetClientAreaOrigin() in wxMSW, unlike in all the other
ports, meaning that for the frames with a toolbar the origin of
wxPaintDC was hidden behind the toolbar itself.
Fix this and ensure that the origin is the point just below (or to the
right of) the toolbar instead.
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.
Fix compilation of <wx/archive.h> on Clang 19 on Fedora.
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.
It has been broken ever since the commit where the code was added,
0037559, 20 years ago.
See #24922.
Because Qt considers the menubar and toolbar parts of the client area
and we need to apply the same fix done for wxPaintDC in this commit
9652958 (translate QPainter into window client area.) to wxClientDC too.
Closes#24921.
If HTML parser has no window connected to it, fall back to black text on
white background as using the system colour can result in unreadable
text if the system is using dark mode.
Closes#24919.
Closes#24920.
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.
No real changes, this is just a refactoring extracting common code in
src/msw/listbox.cpp and src/msw/checklst.cpp into a new header which can
be reused from both places.
As a side effect, wxCheckListBoxItem now uses the wxListBox fix for
background colour from the parent commit, which makes it unnecessary to
set it explicitly in it any more.
Also test customizing the text colour of wxCheckListBoxItem in the
sample for completeness.
Ulrich TelleandVadim Zeitlin
taler21andVadim Zeitlin
Lauri NurmiandVadim Zeitlin
paulcorandGitHub
ali kettabandVadim Zeitlin
Roberto BoriottiandVadim Zeitlin
Bill SuandVadim Zeitlin
Blake-MaddenandVadim Zeitlin
Lauri NurmiandVadim Zeitlin