If you run weston with the headless backend, you get a Wayland
display with no seat, which is just fine by the protocol.
gdk_display_get_default_seat() returns NULL in this case. Various
widgets assume that we always have a seat with a keyboard and a
pointer, since that is what X guarantees. Make things survive
without that, so we can run the testsuite under a headless
Wayland compositor.
Once upon a time, there was a function called gdk_event_get_scroll_deltas().
It returned %TRUE when an event had scroll deltas and that was used as the
condition to decide whether to push scroll deltas to the scroll history,
even when the both deltas are 0 for the stop event at the end of scrolling.
When GtkScrolledWindow kinetic scrolling code was adapted for
GtkEventControllerScroll, it was replaced with a (dx != 0 && dy != 0)
check. This prevented the stop event from getting into the history, and
instead allowed non-smooth scrolling to affect the history as they have
synthetic deltas with one of the values being -1 or 1 and the other on 0.
Instead, check the direction as we already have it as a local variable.
The api contract for size_allocate() vfuncs is
that they must allocate all the children that are
going to be snapshotted in snapshot(). The flowbox
size_allocate() was just bailing out when the children
request a size of 0x0, leading to an assertion in
snapshot() vfunc later. Just allocate all children
a size of 0x0 in this case.
The previous fix broke the case where we're Shift-Tabbing
from a listboxrow child to the row itself. This was causing
the widget-factory2.tab-backward test to fail. Fix it, by
grabbing the focus to the row explicitly.
If a row has content that is focus-on-click, and is set
to focus-on-click itself, then the row steals the focus
fromt he content, since it uses focus-on-click on button
release, as opposed to button press. Avoid that by
refusing to take focus if it is already on some
descendent of the row.
This was showing up in the widget-factory listbox on
page 2, where clicking on the spinbutton would briefly
put the focus on the spinbutton, only to lose it to
the row.
This was not working in the case that the existing child
is not a scrollable. It showed up as crashes of the
scrolling benchmark in gtk4-demo when switching examples.
The previous code was unreffing the window twice, which caused problems
during dialog destruction. Move to g_list_store_find instead of
iterating manually.
ref() the window before and unref() after. g_list_store_remove will
actually unref() the window, since the toplevel_list owns its own
reference.
Fixes#2741Fixes#2742
I thought I could get away with just unrealizing the
window, but it turns out that gtk_window_hide() is the
place where we remove grabs when a modal dialog goes
away, so we ended up with stuck grabs.
Nested main loops are bad, as they introduce layers of complexity caused
by the potential re-entrancy in the case of multiple event sources, like
IPC, threads, etc. Additionally, the programming model they provide—stop
the world while spinning a new loop—does not conform to the event-driven
model employed by GTK.
Replace it with an explicit nested main loop, as we need to block the
signal handler currently being emitted depending on the response of the
overwrite confirmation dialog.
This is a bit of a hack, and the only reason we need it is that the
print dialog will load the last used path as the output file name, when
printing to a file; this means that, in theory, it would be possible to
press Print without selecting a file, and accidentally overwriting an
existing file.
It would be much simpler if we did not store the last used path, and
always explicitly asked the user to select a file; this would avoid
destructive actions, and would allow us to rely on the overwrite
confirmation dialog right inside the file chooser.
Nested main loops are bad, as they introduce layers of complexity caused
by the potential re-entrancy in the case of multiple event sources, like
IPC, threads, etc. Additionally, the programming model they provide—stop
the world while spinning a new loop—does not conform to the event-driven
model employed by GTK.
Let keyboard/pointer paths handle their own events, and find the
current focus. The event will be propagated through instead of
being just emitted on the toplevel.
This makes it handled throughout all the gestures that want to
know about it.
