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: 5d3cec5441)
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.
Fixes#22580.
Closes#23835.
Make the wxString(std::string_view) constructor explicit.
Otherwise, when comparing a std::string_view with a const char *, the
cast to wxString will be considered as a candidate for the comparison,
ultimately causing an "ambiguous overload for 'operator=='" error.
For example, this sample only builds if the constructor is explicit:
#include <wx/string.h>
#include <string_view>
int main() {
std::string_view view = "abc";
const char *str = "abc";
return view == str;
}
However, making the constructor explicit will break assignment:
std::string_view view = "abc";
wxString s;
s = view; // Error: no match for "operator="
That we can fix by implementing operator=(std::string_view)
That, however, introduces another ambiguity:
std::string str = "abc";
wxString s;
s = str; // Ambiguous between s = wxString(str)
and s = std::string_view(str)
That we can fix by implementing operator=(std::string)
Finally, note that some rather obscure ambiguities remain, such as:
wxString s;
s = {"abc", 2}; // Ambiguous between s = wxString("abc", 2)
and s = std::string_view("abc", 2)
Avoiding them is not simple (https://cplusplus.github.io/LWG/issue2946)
and doesn't add much value.
Closes#23834.
When using MSVC, wxScrolledCanvas could be instantiated multiple times
when including wx/scrolwin.h directly and when including wx/grid.h,
which declares a class deriving from wxScrolledCanvas, later.
Fix this by defining a dummy class deriving from wxScrolledCanvas in the
same header, as this is enough to convince MSVC to generate the
definition of wxScrolledCanvas itself in the DLL instead of doing it
inline.
Closes#23774.
Closes#23803.
We never really used the "original" version of the command line, i.e.
before it was (possibly) modified by gtk_init_check(), so don't bother
keeping it and just free the pointers corresponding to the arguments
consumed by GTK in wxGTK code.
There should be no real changes, this is just a simplification.
This is a bit ugly because we need to have some __WINDOWS__ checks in
common code, but less uglier than before, e.g. it allows us to get rid
of wxEntryCleanupReal redefinition hack.
Add support for specifying multiple animations to allow automatically
showing a higher resolution version when using high DPI, just as it was
already possible with the bitmaps.
See #23817.
Don't call IsDialogMessage() for any unknown windows, this is not needed
any longer now that we recognize wxFindReplaceDialog HWND as ours (see
the previous commit) and that its MSWProcessMessage() works correctly
(done in this one).
Removing this IsDialogMessage() call still allows TAB navigation to work
in the "Find" dialog but prevents us from processing unknown messages
for unknown windows, which might have unwatned consequences.
Just refresh the window and repaint it from OnPaint().
This was already effectively done under Mac and now this class can be
also used in wxGTK (where it may be preferable to the native one as the
latter one doesn't support high DPI animations yet).
Deprecate wxXmlResourceHandler::GetAnimation() function which returns
just a single animation and add a new GetAnimations() replacing it.
Use the new function in wxAnimationCtrl XRC handler to pass all the
animations defined in the XRC file to the control.
Allow specifying multiple animation versions, for different resolutions,
when setting the animation to use via wxAnimationBundle class which is a
much simpler version of wxBitmapBundle used elsewhere.
This is not implemented for the native GTK version yet.
Update the sample, even though the difference in it is not really
noticeable as the "high DPI" throbber is just a scaled up version of the
existing standard DPI animation produced using gifsicle.
Instead of always scaling the single bitmap passed to it, allow passing
wxBitmapBundle and select the bitmap most appropriate for the current
resolution from it.
Closes#23813.
It shouldn't be possible to put characters that can't be entered into
the associated control directly by pasting them, so intercept paste
events too and filter out any invalid characters.
Closes#10281.
Closes#23812.
This reverts 5d630caabd (Make it enough to predefine only
wxUSE_DPI_AWARE_MANIFEST, 2023-08-23) and all the commits which tried to
fix the breakage caused by it.
While the original change had merit, it seems to be too difficult to fix
all our build systems to avoid embedding manifest when defining this in
the code, like samples/sample.rc does, so revert this change for now.
Maybe it can be reintroduced in the future after switching to some other
build system.
Remove support for unsupported MSVS versions earlier than 2015
and Windows versions earlier than 7 from CMake build as they are not
supported any longer.
Also update wxUSE_GRAPHICS_GDIPLUS and wxUSE_GRAPHICS_DIRECT2D comments
in wxMSW setup.h to remove mentions of unsupported Windows XP but do
mention that MinGW-w64 can use Direct2D.
Closes#23787.
If this is predefined before including wx/msw/wx.rc, it clearly
indicates that wx manifest should be used, but this was _not_ the case
before as wxUSE_RC_MANIFEST could be predefined as 0 (which is the case
for MSVS, to avoid conflicting with the manifest embedded by it into the
executable by default).
Change this and do include the wx manifest if wxUSE_DPI_AWARE_MANIFEST
is defined.
Newer standard library headers should only be included when the compiler
is targetting that standard, otherwise some compilers (like MSVC) will
warn that you are using a newer C++ include on an older version.
The changes of 8c1234ea66 (Improve assert checking line index validity
in wxGenericListCtrl, 2023-07-24) were wrong for virtual list controls
as the lines vector is not used for them, so restrict the assert to the
non-virtual case only.
Don't just check that the index is not -1, but also that it's valid,
which can catch other problems.
Also replace the ASSERT with CHECK to avoid dereferencing invalid
pointer, it's better to crash when trying to dereference a NULL one.
Previously it only inherited from wxTextEntryBase in the generic
implementation (used e.g. in wxMSW).
Update the code, documentation and add new unit tests checking that
wxSearchCtrl member functions inherited from wxTextEntry behave
correctly.
Closes#23686.
Closes#23697.
This commit reverts cb85871831 (Add MSWShouldUseAutoDarkMode() and use
it for wxSpinButton, 2022-12-07) as, contrary to the expectations of
this commit, other controls didn't use this function and even
wxSpinButton itself doesn't need it any more after the changes of the
parent commit, which were required because automatic support was not
flexible enough.
Explicitly redraw it ourselves instead of relying on DefWndProc() to do
it, as with 15e4f5b (Work around wxListCtrl repainting problems with
WS_EX_COMPOSITED, 2023-06-05) which did the same thing for wxListCtrl,
doing it seems to be enough to make the control draw correctly.
Closes#23656.
Create hidden radio button in wxGTK when using wxRB_SINGLE, as
this lets us deactivate the shown button by activating the hidden one.
GTK does not allow deactivating radio buttons by calling them with
gtk_toggle_button_set_active( ..., FALSE), so we need to work around
it like this.
Also update the documentation to mention that this works in wxGTK now.
See #17022.
Closes#23652.
Closes#23677.
