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.
If a mouse event handler calls Refresh(), increase the likelyhood that a
paint event can be issued before the next mouse event occurs, by requesting
more mouse events from the the end of the handler rather than the start.
See #18314
Don't forbid calling Enable() before creating the window and just do
nothing in this case and do disable the window when it's actually
created if it's supposed to be disabled.
Note that this doesn't work for classes overriding Enable() directly,
such as wxButton or wxCheckBox, currently.
wxWindow::GetContentScaleFactor() always returned 1 before the window
was shown in wxGTK, which was rather annoying as typically icons are
initialized on application startup, i.e. before showing the windows, and
so the wrong scale factor was silently used for them.
It could happen that the window remained as the global "pending focus"
even after it lost its focus, resulting in FindFocus() still returning
it as the currently focused window, even though it didn't have focus any
more.
This notably broke focus logic of wxCompositeWindow and could result in
missing wxEVT_KILL_FOCUS for windows using it, such as wxDatePickerCtrl,
and quite likely was responsible for other focus problems in wxGTK as
well.
No real changes, just add a helper wxDumpWindow() function to make focus
logging less verbose and slightly more readable (as the label is not
shown any more if it's empty).
Include gdk/gdkkeysyms.h from wx/gtk/private/gtk2-compat.h as it must be
included before it for the compatibility header to define the new names
for the key constants even when using old GTK+ versions.
Add wx/gtk/private/wrapgtk.h wrapping gtk/gtk.h in pragmas disabling
these warnings and include it everywhere instead of directly including
gtk/gtk.h.
Also include wx/gtk/private/gtk2-compat.h from this wrapper header as it
was included by 90% of the files including gtk/gtk.h itself and it seems
to be better and simpler to just always include it.
Define g_signal_handlers_disconnect_by_data() if it's not available,
i.e. when using glib older than 2.32 where it was added, to fix the
build under old systems such as CentOS 6 broken by the changes of
8278f7b618 (see #18084).
Also use it elsewhere instead of g_signal_handlers_disconnect_matched()
as it's more readable.
Closes https://github.com/wxWidgets/wxWidgets/pull/760
GTKHandleDeferredFocusOut() is only ever called when gs_deferredFocusOut
is non-null, so there is no need to check for it inside this function
again.
No real changes.
It is often useful to know where is the focus coming from, for example
to determine if was in another window of the same composite control.
Remember the last focus in yet another global variable in wxGTK code to
allow setting wxFocusEvent::m_window correctly when generating
wxEVT_SET_FOCUS events.
