When the original messages language matches the language of the locale
being used, these strings can be used directly and so AddCatalog()
should still return true for them but it didn't do it any more after the
changes of 94b1a17aeb (Add AddAvailableCatalog() and use it in
AddStdCatalog(), 2023-09-30).
See #18227.
Closes#24019.
Closes#24037.
Don't mention thoroughly outdated desktop environments such as Gnome 1
and don't make this X-specific as the situation is not at all better
with Wayland.
Do mention IsAvailable().
See #18081.
Closes#24028.
No real changes, just refactor the code to reset all drag-related
variables in a single function instead of doing it manually in several
places.
As this function also resets m_clickTab, which could previosuly remain a
dangling pointer, change the code to get its value before calling it.
Ensure that all of them are initialized, including m_clickTab, which
didn't seem to be always initialized before.
No real changes (as m_clickTab doesn't seem to have been used before it
was initialized).
Passing an invalid index to this function results in a crash, so ensure
this doesn't happen -- at the very least this would have turned the
crash fixed by the parent commit into "just" an assert failure.
Fix using outdated click position in wxAuiTabCtrl mouse handlers, which
resulted in an invalid wxEVT_AUINOTEBOOK_DRAG_MOTION event being
generated and a crash while handling it.
Ensure that we reset m_clickPt when resetting m_isDragging too so that
we don't decide that we're dragging if the mouse enters the window with
the left button already pressed after a previous drag.
Closes#24027.
It made sense to emphasize its use when this was the recommended way to
set up MSVS projects, but now the simplest (and hence recommended) way
to do it is using wxwidgets.props file, so make the manual setup
instructions more generic as they're most likely to be used with
non-MSVC compilers.
We had instructions for building wxWidgets with MinGW but not for
building the applications using wxWidgets, so add them too now in the
hope that it will be helpful to people who struggle to find the options
to use for building -- or at the very least to the people who have to
answer the questions about this, as they could now just point to these
instructions.
Unlike the traditional C functions, std::from_chars() doesn't skip
leading whitespace and doesn't accept the leading "+" sign, so we need
to skip them explicitly to preserve the behaviour of ToLong() in the
previous wxWidgets versions.
Do use std::from_chars<unsigned long>() in it as otherwise values
greater than LONG_MAX failed to parse.
Handle negative numbers explicitly to still parse them in this function
as well, as needs to be done for compatibility.
Add a test case for the previously failing numbers.
Closes#23957.
This reverts the frame synchronization logic that was recently added
with the purpose of avoiding performance issues due to `eglSwapBuffers`
blocking when the canvas is hidden or occluded.
This logic should be unnecessary after `eglSwapInterval(display, 0)`
is called, since `eglSwapBuffers` should never block anymore.
Furthermore, as it stands now, it causes the canvas to continuously
repaint itself at the refresh rate of the display, which is wasteful
for applications which do not need to continuously refresh.
Fixes#24012.
Closes#24017.
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.
Fixes#23961.
Closes#23968.
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.
Fixes#24013.
Closes#24016.
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.
As documented, the value -1 is special which means no constraints will
be used.
In other words, we should use the Qt defaults if -1 was specified.
Closes#24008.
The Clear log and Exit buttons were not shown after the changes
in a69fabe (Fix using wxStaticBoxSizer in samples, 2023-10-22).
Fix this by creating them with the proper parent.
Closes#24005.
Closes#24007.
Since the changes of 194a7be33f (Improve wxGLCanvasEGL refresh logic
under Wayland, 2023-05-17, see #23554) drawing on wxGLCanvas from
wxEVT_IDLE handler without refreshing the window first didn't work any
longer because the "ready to draw" flag was always false in this case.
To make this work again, refresh the window ourselves to ensure that it
does get redrawn. This is less efficient than drawing on it from
wxEVT_PAINT because all the code executed by the application prior to
calling SwapBuffers() is just wasted, but better than not updating the
window at all.
The recommended way of doing things remains, just as it always was, to
draw from wxEVT_PAINT and call Refresh() in the application code when
the window needs to be updated.
See #23998.
Closes#23996.
When using non-integer scale factor, we need to round the result of the
multiplication by it instead of truncating it for consistency with the
behaviour of wxBitmap::CreateWithDIPSize() and the other places where we
do this, including wxOSX version of this function.
Add a simple unit test checking that this works correctly (it would fail
with wxGTK before).
No real changes, just don't put the test not using raw bitmap access
inside the section guarded by "#if wxHAS_RAW_BITMAP".
This commit is best viewed with Git --color-moved option.
Don't test for 2 unrelated conditions inside the single assert as this
makes it unclear which of them failed.
Separate the checks for bitmap and input parameter validity, just as it
was already done in wxGTK.
Add a note explaining that when creating a button sizer with this
method, one of the buttons will be usually made the default.
See #23992.
Closes#24001.
Include standard library <memory> header file explicitly in the files
where std::unique_ptr<> is used instead of relying it on getting
implicitly included from the other headers, as this doesn't happen when
wxUSE_INTL==0.
Closes#23999.
Since the changes of 4d76a87015 (Make wxSearchCtrl inherit from
wxTextEntry in all ports, 2023-07-09, see #23697) GetEditHWND() returned
null for wxSearchCtrl which was considered to be correct because all
wxTextEntry functions were supposed to be forwarded to wxSearchTextCtrl
anyhow.
This wasn't really correct, however, as GetEditHWND() was also called
from SetHint(), resulting in an assert failure and falling back on
generic hint implementation which, while mostly working, suffers from
some problems that the native implementation doesn't have.
So make this function return the actual HWND used by the associated text
entry to fix this and allow SetHint() to work as before and also
forestall any problems due to not having the right HWND in the future.
See #23983.
Closes#23975.
This should have been done back in f18b415ee3 (Don't crash on startup of
console programs in monolithic wxX11 build., 2011-05-03) when a related
crash on startup was fixed.
