In the recent changes for handling map/unmap events on Wayland's
wxGLCanvasEGL, we use the following GTK widget signals:
* The "map-event" signal to create the canvas's subsurface.
The earlier "map" signal can not be used, as the associated toplevel
window's Wayland surface may not yet exist by the time we receive it.
* The "unmap" signal to destroy the canvas's subsurface.
Using the later "unmap-event" signal is problematic, due to other
resources we build upon being already destroyed by then.
Usually, the "map-event" signal comes before "unmap" and resources are
created and destroyed appropriately. However, there's an edge case:
If a canvas is shown and then immediately hidden (before wxWidgets can
pump from the event loop), "unmap" will come before "map-event".
This happens because signals like "map" and "unmap" are delivered
immediately (when calling e.g. `gtk_widget_hide`), while signals like
"map-event" and "unmap-event" are delivered later on the event loop.
For the same reason, showing a canvas, then immediately hiding it, then
immediately showing it again, will cause two "map-event"s to get
delivered enqueued without a "unmap" in between.
This condition can be hit quite easily when setting up a complex UIs,
and in particular it is triggered by Aegisub during startup, leading to
a crash (Wayland protocol error) when opening a video later, or when
specifying a video directly on the startup command line.
To avoid this breaking our resource management, add some checks to detect
those "map-event"s we shouldn't handle - either the ones that happen
after "unmap", or the duplicate ones without an "unmap" in between.
See #23961, #23968.
(cherry picked from commit 133f7731b25df46bd99519e7c52cf4a90ca2cc1a)
If the wxGLCanvas is destroyed immediately (without hiding it first),
the GTKs widget's `unmap` signal which usually destroys the Wayland
resources is not emitted. Thus, we need to ensure they are destroyed
on the destructor instead.
This fixes an use-after-free issue, sometimes causing a crash, because
one of the leaked resources is the canvas's Wayland frame callback.
See #24013, #24016.
(cherry picked from commit 22ae7a58b5412463194b446426296b588368bff8)
Calling it from the frame callback might change the swap interval for
the wrong context if the active context got changed in the meanwhile,
but by the time SwapBuffers() is called the correct context must be set.
Doing it there also allows to unify X11 and Wayland code branches.
See #24014.
(cherry picked from commit 64afa9d96341f3696ba5311d36fd3a82f7c9de77)
Don't use m_readyToDraw in it, as the canvas is still shown even when
it's not ready to draw yet, and use m_wlSubsurface instead as it is
destroyed when the window is unmapped.
See #23899.
(cherry picked from commit cf44a87ec62f9cefb428b8d6c002c2ee342dc4ec)
No real changes, just clean up the code a bit to make sure we get a
-Wswitch if any elements are added to wxDisplayType enum in the future.
(cherry picked from commit d128afe1e8fff6fbd16c46ffbe30eaba706ff274)
Change implementation to use Sonoma-supported version of the application
activation call.
See #23893, #24003.
(cherry picked from commit 695ca042895468a8ce6c1a84422882adb3c63ee9)
The memory leak fix in b52728a62a (Fix memory leak of wxClipboard data
on exit, 2023-06-21) was too eager and destroyed not just the currently
used selection (e.g. primary), but also the other one (secondary) when
Clear() was called, which was wrong and resulted in the loss of
clipboard contents when discarding the primary selection in wxSTC, for
example.
Fix this by only deleting the object corresponding to the selection
which we're clearing.
See #23661, #23988.
(cherry picked from commit dc6a0c069bdde714f22cb0459efd9ad186ce7179)
Changing the selection could behave wrongly and result in an assert
failure as the selection anchor could have become invalid, due to the
change of the number of items in the control.
Fix this by invalidating it when this happens.
(cherry picked from commit 5885eea5ea72434311f2c706f57cff92a09ade91)
The leak check is done before the FlsAlloc()-installed callback function
runs in this build variant and so reports wxThreadSpecificInfo object,
and everything it contains, as leaked, even if it isn't, really, so
deallocate it explicitly ourselves in this case.
Also call wxThreadSpecificInfoTLS::CleanUp() from the main thread as
well, which fixes a possible real (albeit one-time only, so not really)
memory leak under XP where FLS API is not available.
A console program should not really be linked with the GUI library, but it used
to work, and it's unavoidable with the monolithic build, so fix the regression.
See #23981
(cherry picked from commit 4cabfa111ab5912ae30d6d44b917a9c403845b3f)
Correct the too hastily backported change of cb69e76897 (Fix not
refreshing generic wxListCtrl after deleting last item, 2023-10-06)
and use NULL instead of nullptr in this branch.
Mark it as deprecated in the documentation without deprecating it
formally in the code, as it seems to be used in some existing code and
there is no urgency to remove it, but using it in new code still doesn't
make any sense.
See #23945.
(cherry picked from commit 543fd3fabcb6d88a6e220520c41501c3f961dd55)
The check for the line being deleted being in the visible range
prevented us from refreshing anything at all if the line which was just
deleted was the last line of the control.
(cherry picked from commit 8d036af8160d303b67944d781d27ff58b058f839)
These patterns are supposed to match all files and not only files with
extensions, but our own code only matched the latter.
Switch to using shell PathMatchSpec() function to check for matching
instead to use the usual Windows rules.
See #23905, #23910.
(cherry picked from commit a4d2e36cec16d511e461496f3eecbcb6f3e7343b)
The new function only returns true if the catalog could be really
loaded and not if it is considered not to be needed because the message
ID language (which is typically "en-US") happens to be present in the
preferred UI languages list (which seems to always include "en-US" in at
least Western European MSW).
This allows to distinguish, albeit in a rather awkward (but
backwards-compatible) way between having a translation for the given
language and not needed such translation.
It is still not clear if it is really correct to return "en-US" from the
list of preferred languages even if the user has never intentionally
configured the OS to indicate that English is acceptable, but at least
now we can work around this issue and use AddAvailableCatalog() in
AddStdCatalog() to make sure we only skip loading unversioned wxstd.mo
if the versioned wxstd-x.y.mo file is really found instead of never
doing it, as was the case until now (see #23886).
Also add GetBestAvailableTranslation() helper which seems more useful
than the existing GetBestTranslation() one and is similarly related to
it.
See #18227, #23930.
(cherry picked from commit 94b1a17aeb12a1ec723a255089be16cd31a268a2)
When the wxWidgets sources are in a path containing '++', CMake would
show errors on the command line:
[cmake] RegularExpression::compile(): Nested *?+.
[cmake] RegularExpression::compile(): Error in compile
This happens because the full path was interpreted as a regular
expression when creating the source_groups. Without wxSOURCE_DIR the
regular expressions still match and create correct source groups, so
remove it.
See #22738, #23943.
(cherry picked from commit b9b0724de141696edf817fb032aa51daf699b48b)
Remove any remaining mouse messages from the input queue after showing
the file dialog because they somehow remain after it is destroyed and
could be processed by the application once wxFileDialog::ShowModal()
returns, resulting in phantom events being processed by the controls
that just happen to be under the button of the file dialog that was
clicked to close it.
See #10924, #23944.
(cherry picked from commit ffc99bd487731629308af9af79205003b7d7e3b0)
We need to set the window type hint to COMBO in order to use a popup
window for it under Wayland and while not doing it seems to still work
with GNOME/mutter, it is required with the other compositors such as KDE
Plasma or Sway and doesn't seem to do any harm under GNOME, so do it
always and hope that it doesn't result in any problems with not
combobox-like popups.
This basically undoes 62d934aab8 (Don't set HINT_COMBO as wxPopupWindow
is used for different windows as well, 2008-10-07).
See #23931, #23908.
Co-authored-by: Alex Shvartzkop <dudesuchamazing@gmail.com>
(cherry picked from commit 5c0cc72cb838371a823e2469a044a4cf92fb6a5f)
The control doesn't update the button itself, even in the recent Windows
versions, so do it ourselves.
It might be better to use I_CHILDRENCALLBACK and handle TVN_GETDISPINFO,
but this looks like a safer change, so do this for now.
See #23718, #23734.
(cherry picked from commit 3ed273ce98083e2e9c81bfb550a68ed4b322ae88)
Don't dereference sm_abortWindow without checking that it is non-null in
wxAbortProc(): even though it's not supposed to happen, it still somehow
does, apparently, so just log a debug message instead of crashing in
this case.
See #23927.
(cherry picked from commit 9a728192c4340b34d2509898f7f16b767a794ac9)
Use a dirty hack to ensure the window is created (roughly) as tall as it
needs to be instead of being created too small and truncating the text
in it.
See #23936.
(cherry picked from commit 71001385c6d66412f3f07b0fdc5a8d5ab022f296)
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, #23652, #23677, #23839.
(modified cherry-pick of b84b45161a2952bc3706fa87619e2bf9d8237f22)
Improve error handling when EGL version is less than 1.5: fail earlier
and with more clear error message.
See #22325, #23855.
(cherry picked from commit 19ed2580d39b0f0914ee89556cce340bfe09a1c0)
Set EGL swap interval to 0 to prevent EGL functions from blocking for 1
second when the window is entirely obscured, resulting in catastrophic
slowdown of the entire program whenever this happened.
See #23909, #23512.
(cherry picked from commit aaabb840b59d24796f521a1174dc428999a2a5a3)
Improve consistency of checkboxes in wxListCtrl between virtual and
report mode, and between the generic and MSW implementation, see #23869.
See #23890.
(cherry picked from commit e8faf2f56c4f0205a195cbeca66e03874d980577)
Setting full size of the dialog before showing it doesn't work, but
setting its client size does.
It could be better to change wxWindow::Fit() itself to do this, but this
might have other effects, while this change should be pretty safe, i.e.
not break anything for the other platforms while fixing a big usability
problem with wxGTK/Wayland: as this dialog is not resizeable, making it
too small initially, as happened before, meant that parts of it couldn't
be used at all.
See #23924.
(cherry picked from commit 532ee2067b5101c079b162644401ed11d418a65f)
When calling wxSimplebook::ChangeSelection(), the focus remained on the
previous, now hidden, page, unless it was explicitly set to one of the
controls on the new page.
This was completely unexpected as it could result in the user
(inadvertently) changing the values of the already "accepted" controls
on the last page, so don't let this happen and always set the focus to
the new page explicitly, even if this hasn't been done by
ShowWithEffect() which doesn't do it at least under wxMSW.
See #23914.
(cherry picked from commit 7e9d06f58436300243fe3b8b076dc222b63dea2e)
There were two related problems: first, any attempts to set the
background colour for the cells without values were simply ignored
because we didn't call wxDataViewModel::GetAttr() at all from
PrepareForItem() in this case and, second, PrepareForItem() itself was
not called when repainting the control neither, resulting in the
existing attribute being reused for the items without values, meaning
that they used the last background colour that was set instead of at
least not using any background at all.
Fix both of the problems for the generic version. Unfortunately the GTK
one still doesn't allow setting the background for the empty cells, but
at least when not doing it the code now consistently leaves them without
any background.
The following code can be added to MyMusicTreeModel in the dataview
sample for testing this:
--------------------------------- >8 --------------------------------------
bool GetAttr( const wxDataViewItem& item, unsigned int col, wxDataViewItemAttr& attr) const override
{
if (col != 1)
return false;
if (IsContainer(item))
{
if (item != m_pop)
return false;
attr.SetBackgroundColour(*wxYELLOW);
}
else
{
attr.SetColour(*wxYELLOW);
attr.SetBackgroundColour(*wxLIGHT_GREY);
}
return true;
}
--------------------------------- >8 --------------------------------------
See #23708, #23902.
(cherry picked from commit fe420caa3bc966b968be985fbba0c0ff5a897546)
NSBox used as a separator must have its type set to NSBoxSeparator.
This apparently didn't matter before in practice, but starting with
macOS 13, separators - i.e. narrow NSBoxes - without the type correctly
set are invisible.
See #23913.
(cherry picked from commit f25103313ed0512837b50774fb81bdb40ad45a41)
The dark style setting does not cause a dark theme to be used
automatically, so request it explicitly.
See #23764.
(cherry picked from commit 9b9ec141fbcd604aa8bfc83da6f16fc9bf5c32e0)
Co-authored-by: Colin Kinloch
Since a261c80 (Avoid Gdk-CRITICAL warnings when using PopupMenu() with
Wayland, 2022-04-22) popup menus shown when there is no related current
event did not work when using default positioning. Fix this by always
providing a GdkWindow and a GdkEvent, and using a suitable substitute
when a real event is not available.
See #23892
(cherry picked from commit df6366ff57371f9d2d41f748514d25259e393203)
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.
See #10281, #23812.
(cherry picked from commit bd4650767fe52f8dd2955b802d2dfb3262cc8dd0)
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)
