It takes half a second on my system to initially
populate the Emoji chooser. That is too long. Do
the work in 8 millisecond chunks to give GTK a
chance to get some frames done.
We were hardcoding that GtkApplicationWindow only
has a single action group with prefix 'win', but
that is no longer the case. Simply use the code
for the general widget case that can handle multiple
action groups.
I was a little overzealous when going
for the new default handling here. We
can't switch to gtk_widget_activate_default
before we actually handle the default.activate
action.
Display changes now happen exclusively through
the ::root and ::unroot vfuncs. Third parties
can observe display changes by listening
for notify::root.
Export gtk_widget_root/unroot privately,
make them work on roots, and use them in
gtk_window_set_display. This gets us to a
single way to listen for display changes,
the root property.
Currently, we sometimes emit display-changed
when the display changed, and sometimes we don't
since the display is changed via gtk_widget_root.
Listen for notify::root as well and update our
display. This is a temporary fix - all display
changes should go through gtk_widget_root,
eventually.
The specification for border-radius goes
top-left top-right bottom-right bottom-left.
The css for the add button in the color
chooser got this wrong, and was showing
a broken top-right corner.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1856
We are now getting focus-out and focus-in events
when the Emoji chooser is shown and hidden, and
this is causing the text to select-on-entry before
inserting the Emoji, which then deletes the selection.
Avoid this by saving and restoring the selection
when presenting the Emoji chooser.
That a property can't be set does not mean
its value can't change. This was showing up
as the cursor-position and selection-bound
properties in GtkText not showing their
current value in the inspector.
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.
