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.
It is unreliable to use the widget dom api to locate
action widgets. For example in a headerbar, they might
be deeper in the hierarchy, with boxes in between.
Therefore, make GtkDialog keep a list of action widgets,
and use that when operating on action widgets.
When GtkBox stops being a container, GtkShortcutsSection
will also no longer be a container. So, stop overriding
container vfuncs, and instead add a buildable implementation
that does the right thing.
When GtkBox stops being a container, GtkShortcutsGroup
will also no longer be a container. So, stop overriding
container vfuncs, and instead add a buildable implementation
that does the right thing.
