Fixes hiding a wxGLCanvas on Wayland, either directly (`->Show(false)`)
or indirectly (e.g. when it is contained in a wxNotebook).
On Wayland, unlike on X11, to show the canvas on the screen, we need to
create a Wayland subsurface. This subsurface is detached from the GTK
widget associated to the canvas, thus it is not automatically mapped or
unmapped when the associated GTK widget is.
Rather, we need to manually keep it in sync with the widget's state.
Knowing what has to be done to map and unmap the canvas, while dealing
with edge cases properly, is not easy to someone not used to Wayland.
When the canvas is mapped, we have this graph of resources:
EGL Surface (m_surface)
|
|
v
wl_egl window (m_wlEGLWindow)
|
|
v
Canvas wl_surface GDK's toplevel window wl_surface
(m_wlSurface) (gdk_wayland_window_get_wl_surface(w))
\ which is shown to the user
\ ^
\ /
\ /
v /
Subsurface (m_wlSubsurface) to overlay
the canvas onto the toplevel window
A simple way would be to destroy everything (m_surface, m_wlEGLWindow,
m_wlSurface, m_wlSubsurface) on unmap, and re-create it again on map.
Inefficiencies aside, this mostly works. However, it can mess with the
current OpenGL context. For example, suppose we have a (fragile)
program that places a canvas inside one of wxNotebook's tabs, and makes
the OpenGL context current only once at startup (e.g. on wxEVT_SHOW).
Switching between tabs will destroy and re-create the EGL Surface, so
the canvas will not be properly rendered when going back to its tab.
So we need to be smarter, and find some way to hide the subsurface
instead. The obvious way would be to unmap the canvas wl_surface
(m_wlSurface), as according to the Wayland spec., "a sub-surface is
hidden [...] if a NULL wl_buffer is applied [to the canvas surface]."
(https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_subsurface)
However, as far as I can tell, this can't be done. There's no API to
hide an wl_egl window, and directly applying a NULL wl_buffer to the
canvas surface initially hides it, but seems to breaks the associated
window so that it crashes when one attempts to show it again.
So what remains, is destroying the overlay subsurface (m_wlSubsurface).
When doing it, to the spec, "the wl_surface is unmapped immediately.".
And not only does this work, but it also deals with the annoying fact
that on current GTK3 versions, when the GDK's toplevel window is
unmapped, its wl_surface is not just unmapped, but entirely destroyed.
(Side note: This may not have been intended, and has been changed for
GTK4, see: https://gitlab.gnome.org/GNOME/gtk/-/commit/5d3cec5441ca)
So we'd have to re-create the subsurface because of this anyway.
So, this works nicely, and as far as I can tell (documentation is a bit
scarce), there's no problem to leaving m_wlSurface (and its associated
m_wlEGLWindow and m_surface) unmapped in this way.
See #22580, #23835.
(cherry picked from commit 952de605f622cc7a3c30257365046ecd1a307808)
Set a flag in insertText and send wxEVT_KEY_DOWN ourselves from
DoHandleKeyEvent() if it wasn't set to ensure that we generate these
events for the keys ignored by the standard insertText, such as
⌘+⎇+Letter combination.
See #23671, #23699.
(cherry picked from commit 30fbb9405335ff9a2843a35e1bfe26b22bb114e7)
Document previously undocumented macOS methods
enabling/disabling automatic character substitutions.
This should have been part of 90e1769 (Add API to control
OS X wxTextCtrl’s smart behavior, 2016-10-16).
See #23889.
(cherry picked from commit 081b7c430b92c05e6dca25c4d4f1f462e3d91e77)
The gestures frame created its own log target and deleted
the previous one but did not restore it when being closed.
This left the current log target invalid which led to a crash
when calling any wxLog*() function after gestures frame was closed.
Fix this by restoring the previous log target when gestures frame
is closed.
See #23767, #23881.
(cherry picked from commit 8efb1bceda202a26380e6491aa00504097a4bb26)
Using the "left" and "top" margin doesn't work in this case and we would
actually need to use "bottom" and "left" ones to offset the origin
correctly in landscape orientation (and something else for the reverse
landscape, and reverse portrait one, too), but there actually seems to
be a simpler way to put the origin where we want it without translating
it explicitly: we can just tell GTK that we want to use the full page,
rather than just the printable area, by setting "use-full-page" property
to true, so simply do this instead.
Co-authored-by: Alex Shvartzkop <dudesuchamazing@gmail.com>
See #23860, #23870.
(cherry picked from commit b12676659591cde32c18f7493089856fba8217d5)
gdk_display_sync() can cause the event loop to run under Wayland, and
gdk_display_flush() seems to work just as well, so use that instead.
See #23760.
(cherry picked from commit f6c3393741873191ee845fb3851f80fea1ec38fb)
Replacing the table used by the grid could make the current cell
coordinates invalid, resulting in asserts when trying to use it later.
Fix this by calling the same function which was already called when
changing the existing table.
See #23751, #23752.
(cherry picked from commit e570d85164af9a2bb1bf6ebb9a061cda97f1ae56)
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
Use wxBitmap::CreateWithDIPSize() to ensure that the backing store
bitmap uses the scale factor corresponding to wxRichTextCtrl using it.
This fixes layout problems in wxRichTextCtrl when using non-default DPI.
Closes#23828.
Closes#23861.
(cherry picked from commit c472e495faea15b349d1ffdad6203543727216af)
Ignore chunks having informational data instead of failing to load WAV
files containing them.
See #23859.
(cherry picked from commit 5c86933fd39ecc240fbb1d5af68ab52d8fc8bf64)
Add DoRefreshLabels() to wxFileHistoryBase::Load() to ensure that the
paths are formatted correctly.
See #23799, #23857.
(cherry picked from commit 879cc1e574e963d182b65fb7989b004f0bf84aeb)
Check that we have a label before repositioning it fix the crash
introduced by 54684be79d (Fix position of label window in wxStaticBox
after DPI change, 2023-08-05).
See #23740, #23826.
(cherry picked from commit 329d35b922aa893c292d14061fb099aacb4af20b)
Changes using XKB for getting key codes for the events in wxGTK resulted
in always using the key codes for the US keyboard which was incompatible
and arguably wrong too.
Change the logic to only use XKB when we don't have a valid key code in
the current layout to restore the old behaviour.
See #23680, #23818.
(cherry picked from commit 3492bacde5c1985257ea1e85e506093dadc12efa)
The existing code prevented the other handlers from processing this even
for no good reason, so don't do it any more.
See #23811, #23815.
(cherry picked from commit cd8a854dce8098d27e9b5c6f8d4a731717728482)
Handle multiple semicolon-separated paths in <bitmap> elements which are
used to provide several versions of the same bitmap in different
resolutions.
This commit is best viewed ignoring whitespace-only changes.
See #23795.
(cherry picked from commit ab88fecdc568857e1ca0f00529dcd92dc71a164c)
Notably, give a clear error if an input file is not found and also check
that the temporary output file could have been written successfully.
Still continue handling the other files even if some of them couldn't be
found in order to give all errors at once if there is more than one
missing file.
(cherry picked from commit 13d8adb4e14c38dd7e8531f263d778dfbb0a0630)
The recently released 0.10.0 doesn't seem to have any actual changes but
has new dependencies which broke the previously working builds.
See #23800.
(cherry picked from commit 55c704a1b404bb302f2fb0a8d9589ab841fcfc92)
alpha and ia64 use libc.so.6.1, GNU/kFreeBSD uses libc.so.0.1, and
GNU/Hurd uses libc.so.0.3, so check for these versions too in addition
to 6 and 7 used under x86 Linux.
See #23801.
(cherry picked from commit 62f75c235db169bf57beaa61694b3c5db95e5e60)
The code example in wxColourDialog documentation used
a wrong type to create wxColourDialog instance.
See #23793, #23794.
(cherry picked from commit 547d49f68bc9241f693e85a4731689ee6d2ac189)
The note in the method description incorrectly stated that
"...the handlers are deleted in wxFileSystem's destructor so
that you don't have to care about it." However, unless a
handler is removed by calling wxFileSystem::RemoveHandler()
(or undocumented wxFileSystem::CleanUpHandlers()), it is deleted
only when wxWidgets shuts down in wxFileSystemModule::OnExit().
Update the method documentation that it is correct (and similar to
that of wxImage::AddHandler()).
See #23789.
(cherry picked from commit af453674b66f79048f05f934559618c9d2522570)
Use the French date format expected by Cygwin CRT which differs from the
one used by MSVC.
See #23782.
(cherry picked from commit 15d7aaaa50c0e815a3d3b94dece365eaffe6653c)
While running the test_base on CYGWIN, this message will be printed on the console:
-------------------------------------------------------------------------------
DynamicLibrary::Load
-------------------------------------------------------------------------------
/cygdrive/c/Users/carlo/Documents/GitHub/wxWidgets/tests/misc/dynamiclib.cpp:26
...............................................................................
/cygdrive/c/Users/carlo/Documents/GitHub/wxWidgets/tests/misc/dynamiclib.cpp:80: warning:
Couldn't find libc.so, skipping DynamicLibrary::Load() test.
/cygdrive/c/Users/carlo/Documents/GitHub/wxWidgets/tests/misc/dynamiclib.cpp:84: warning:
Possible candidates:
/lib/libc.a
/usr/lib/libc.a
CYGWIN uses NEWLIB as C library and it is compiled into cygwin1.dll.
This patch adds the right test case for CYGWIN, for letting the execution of the test.
See #23781.
(cherry picked from commit 1bc8631b527603c855d65a9ede45fa3d6e672ea8)
Add another manually created solution file, after adding the solutions
for MSVS 2017 and 2019 in cfe4a10995 (Add manually created MSVS 201x
solutions files for wxrc, 2019-01-07) to make it possible to build wxrc
with MSVS 2022 easily too.
(cherry picked from commit 9e8ab658fe87f621b3a5c96e4df43c588d6fd23b)
Unlike in master, only the variants for the date/time formatting context
are returned to reduce the number of changes in this branch. This is
wrong for standalone month names like in the generic calendar control.
However, in the prior implementation that was also the case.
Use a horrible hack to avoid adding new virtual functions to
wxUILocaleImpl class which, although private, still somehow results in
ABI breakage.
See #23556, #23581.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
Provide the correct options for wxBUILD_TESTS in the CMake part
of unit tests documentation.
See #23745, #23746.
(cherry picked from commit 350222e411597fcfebf367f72a99c29fdda6c3c1)
The Linux distribution community has somewhat deprecated the lsb_release
utility and has standardized on a new file, os-release, that can be
simply parsed to get the same information. Attempt to read this file in
/etc/os-release, then /usr/lib/os-release, and finally, fall back to
using the lsb_release utility if neither of those files are found.
See: https://www.freedesktop.org/software/systemd/man/os-release.html
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2184391
See #23712.
(cherry picked from commit aef7df6c9f44f751d97f4f6519ae6e5c3b81019d)
This didn't update the number of selected items, which resulted in other
problems later on, including accessing items with invalid index which
could lead to a crash.
This is a modified version of d6dd0ebb6e25ac4fbde7f3cca2074be42a54c10d
from master.
See #23729.
Ensure that we only increase the dialog width but never decrease it to
prevent the dialog from jumping annoyingly to different size with each
label change.
The previous attempt to do this in 4101849b4d (Grow
wxGenericProgressDialog automatically if needed, 2017-10-27) didn't work
because it seemingly didn't take into account the fact that wxStaticText
width changes when its label changes and so calling SetLabel() could
make it smaller, meaning that the next update would call Fit() again.
So fix this by preventing the control from changing its size by using
wxST_NO_AUTORESIZE and then only resizing it manually if it really needs
more space.
See #10624, #23727.
(cherry picked from commit 97546a6f0cf941ce94b42a27b23f51e224c8e54e)
libwebkit2gtk-4.1 has the same API as libwebkit2gtk-4.0, except that the
former links with libsoup-3.0 and the latter links with libsoup-2.4.
Fixes#23630.
(cherry picked from commit 1b8664426603376b68f8ca3c54de97ec630e5940)
If the printer name is specified, avoid fall back to the default printer
via the use of PRINTDLG, as the default printer DEVMODE may be
incompatible with that of the printer we're actually going to use and
could possible result in a crash if their size differs.
Use a temporary printer if necessary to retrieve the correct DEVMODE for
the given printer name.
See #23685.
(cherry picked from commit e35257d2b6fdc301c1f76f514350191bedebf0bd)
The previously computed best size may become invalid after inserting new
items, so forget it.
See #23681.
(cherry picked from commit a9d2a140900f8214f7d724889fcf9f06c27db7d2)
Somehow many entries got added to the wrong section and went under 3.2.2
instead of 3.2.2. Move them to the correct place now.
Also reintegrate the section for the changes in 3.2.2.1 which wasn't
present in this branch.
