When a modal dialog is smaller than its parent,
we were keeping the resize cursor from the dialogs
edge all over the parent window, which looks
really irritating, since the resize cursors are
closely associated with the window edge. Fix
this by falling back to the default cursor
outside the grab widgets surface.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/23
We don't support that setting life-updating anyway. So, instead of
getting the value *every time we format a time*, get it once for the
filechooserwidget and reuse that value.
The spinbutton>button>image is currently blue when the image is clicked
and dark-ish when the button is clicked(but not the image). This was not
the case before since we didn't even propagate :active down to the image
child. Fix this by only applying the blue color to direct image children
of entries.
The old default of 148px doesn't work everywhere. Instead, pick a
default value of -1 and measure() the sidebar widget in the
filechooserwidget in that case. Other values >= 0 are still handled as
before.
Leave it to the ::hits-added handler to switch to the list of search
hits. This way we don't get a weird transition when the current search
didn't have any hits and the next one doesn't either.
Searches with hits still feel good.
Set the cursor on the surface of the target
widget, not the surface of some of its parents.
This does not make a difference currently.
But it will in the future, when we have
parented widgets with surfaces.
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
