The default widget is mostly a dialog concept,
and does not really need this generic api.
If you need to mark a widget as default,
use gtk_window_set_default() directly.
We used to handle has-default specially in ui
files. It was awkward, so stop doing that. If you
need to influence the default widget in a window,
you can just set the default-widget property.
Instead, use the new way of activating default.
I think most of the default handling in
GtkFileChooserDialog should be dropped, but
for now this keeps things working.
Activating this action will replace other
activate_default apis. It is more flexible,
since intermediate widgets can intercept the
action and do their own handling.
This api wasn't used anywhere in GTK. And since
we've dropped the variant for the default widget,
this one should go too. If it is needed, it should
become and action too.
We used to handle has-focus in ui files specially.
It was awkward, so stop doing that. If you need
to influence the initial focus of a window, you
can just set the focus-widget property.
When hitting Escape in the location entry,
we were not moving the focus anywhere,
causing focus to be NULL, and key bindings
to stop working. The visible effect was
that Ctrl-L / Escape / Ctrl-L would not
get back to the location entry, as expected.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1851
When hitting Escape, the file chooser will go
into search mode, because the search entry
consumes the key to emit the ::search-stopped
signal. Recognize this situation and avoid
switching to search mode in this case.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1850
The primary icon is on the right in RTL, so don't offset the text child
to the right for it.
Fixes the text and icon overlapping in the second entry
in tests/testentryicons
It doesn't make sense to keep track of all the last_* values anymore now
that widgets only get allocated when their size changes anyway.
Remove all the associated (and thus now unused) flags as well.
We were forwarding key events to the search entry
and unconditionally considered search started
afterwards. That is not correct, since things
like a Ctrl key press should not trigger search.
Fix this by only switching to search mode when
the event was actually consumed.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1829
The key capture was interfering with other
entries in the dialog, so be smarter about
when we want to capture keys and when we
don't.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1842
Just measuring it (so the warning goes away) but then not using the
values will later underallocate the text widget.
Instead, always reserve space for the icon (which will inevitable be
visible as soon as the searchentry is actually being used).
Fixes#1831
