No real changes, but don't complicate the constants definitions
needlessly just to avoid changing the numeric value of WXK_LAUNCH_APP
constants as nobody should rely on them anyhow.
Not doing it simplifies things and allows to condense the mapping from
GDK keys to wx ones.
X11 defines Xf86Launch[0-9a-f], which are then also defined as
GDK_KEY_Launch[0-9A-F].
Unfortunately, keys which are not mapped are just plain ignored and the
application is then not able to receive these keyboard events at all.
The original PR https://github.com/wxWidgets/wxWidgets/pull/157 mapped
only LaunchA/B to WXK_LAUNCH_APP1/2, this patch adds the whole range of
keys and keeps LAUNCH_A/B as aliases for WXK_LAUNCH_APP1/2
There are still plenty of X11 keys which have no WXK mapping and might be useful
for applications to act upon.
Instead of trying to remap all of them, generate a WXK_NONE key event and let
applications deal with it using GetRawKeyCode() if appropriate.
This function was defined in wxGTK and wxOSX, but not in wxMSW or the
other ports, but it can be useful there too, so make it public and
define it in common code.
When touch events were enabled, normal mouse move and click events were
not generated any longer. Fix this by doing the following two things:
First, emulate the LeftDown, LeftUp, and Motion events, that are no
longer triggered when using the "touch-event".
In addition, remove GDK_BUTTON1_MASK in the press callback, that is
never set when using a mouse, but that is set for some reason by GTK
when using a touchscreen.
See https://github.com/wxWidgets/wxWidgets/pull/2539Closes#19265.
Signed-off-by: Thierry Bultel <tbultel@free.fr>
We accidentally ended up with two functions doing the same thing, since
DoGetBorderSize() was added in 743b426605 (Added DoGetClientBestSize()
and use it for a couple of controls in wxMSW., 2009-06-22), as we
already had GetWindowBorderSize() added even earlier in 333d70525c
(added wxWindow::GetWindowBorderSize(), 2006-11-25), so remove the
redundant non-public function and use GetWindowBorderSize() everywhere.
This does change the behaviour of GetWindowBorderSize() in wxMSW, wxGTK
and wxUniv, as it now does what DoGetBorderSize() used to do, but this
should be an improvement, as DoGetBorderSize() implementation was more
precise.
Connect to key-{press,release}-event on the "focus widget" rather than
the main widget, to ensure that we get them before the native control
does and so can generate the key events even for the keys handled by the
control internally.
This allows to get events for the arrow keys in wxDataViewCtrl, for
example, while previously these keys were consumed by the control
itself, as could be seen with the following patch to the sample
---------------------------------- >8 --------------------------------------
diff --git a/samples/treelist/treelist.cpp
b/samples/treelist/treelist.cpp
index af6905cecb..74894cc9a9 100644
--- a/samples/treelist/treelist.cpp
+++ b/samples/treelist/treelist.cpp
@@ -349,6 +349,10 @@ bool MyApp::OnInit()
sizer->Add(textLog, wxSizerFlags(1).Expand());
SetSizer(sizer);
+ m_treelist->GetView()->Bind(wxEVT_KEY_DOWN, [](wxKeyEvent& e) {
+ wxLogMessage("Key in tree: %d", e.GetKeyCode());
+ e.Skip();
+ });
// Finally show everything.
Show();
---------------------------------- >8 --------------------------------------
Pressing arrow keys didn't generate the expected message before (unless
the focus was on the control header and not on the main area itself).
This may fix similar issues with other controls setting m_focusWidget as
well.
3217a4e8a2 (Fix best size for windows which are hidden when TLW is shown
with GTK3, 2021-04-30) did not account for possibility that window needing
revalidated best size is also the TLW.
See #16088
Relying on "check-resize" to detect when a "size-allocate" is in progess is
insufficient, resulting in the possibility of a window ending up with the wrong
size or position after inital layout. Using our existing "size-allocate"
handlers should be enough to detect the cases we care about.
See #18865
Limit the changes of d06e97e8d9 (Make sure toplevel is active in
SetFocus(), 2020-07-08) to GTK 3 only as they break GTK 2 GUI test
suite, resulting in many CI failures.
See #18783.
Restore IsFocusable() check that was commented out, without any real
explanation, by c7bfb76a2c (A number of focus handling improvements:
Left clicking on a window only focuses the window if not processed.
wxControlContainer::SetFocus moved to wxControlContainerBase so that a
container now focuses the first child even on wxGTK. wxAuiBook is now a
container, need for correct navigation on wxGTK., 2007-08-18).
This is needed to avoid giving focus on click to the windows that
explicitly override AcceptsFocus() to return false, as e.g.
wxGridColLabelWindow and other wxGrid subwindow classes do. From the
user point of view, previously clicking on a grid row/column label just
disabled the user of arrow keys, which was very inconvenient (and didn't
happen under MSW).
This doesn't work anyhow, so it's better to prevent the code doing this
from compiling instead of getting run-time asserts or worse.
Also simplify construction of these events inside wxWidgets by passing
the window itself to the ctor instead of passing just its ID and calling
SetEventObject() separately later.
For consistency, do the same thing for wxNcPaintEvent too.
Put common code from all the different ports into it.
This is not very useful right now, but it will allow to change this
function once, instead of applying the same change to all ports, in the
upcoming commit.
If the popup menu position was explicitly specified, it wasn't taken
into account correctly in wxGTK code as it always clamped it to the
primary display boundaries, even if the window showing the menu wasn't
on this monitor at all, typically resulting in the menu shown at the
left or right edge of the monitor instead of the correct position.
Fix this by using the display containing the window instead. This
requires passing the window, or rather the menu from which it can be
retrieved, to wxPopupMenuPositionCallback too, so add a helper struct to
pass both the position and the menu to it.
Closes https://github.com/wxWidgets/wxWidgets/pull/1621
If neither main widget nor connect widget is focusable (which notably
happens when they're the same anyhow, as is the case for wxChoice, for
example), still use the main widget as mnemonic instead of not using any
mnemonic at all.
This fixes activation of a wxChoice preceded by wxStaticText by pressing
the key combination corresponding to the label mnemonic, which didn't
work previously.
Due to a wrong "else" in RealizeTabOrder() implementation, we could set
the mnemonic widget for a previous widget using mnemonics (i.e.
wxStaticText or wxStaticBox) rather than the one closest to the actual
control activated by the mnemonic.
