They are not usually yellow anymore, the previous advice about how to
style them was for pre-3.20 versions, and the immediate replacement (CSS
class .tooltip) does not seem ready for primetime.
https://bugzilla.gnome.org/show_bug.cgi?id=784421
No longer store variation sequences explicitly. Instead, put a 0
in the sequence where the modifiers will be inserted. This is more
compact, and it allows us to put variations directly into the
recent section.
Update the type of the recent-emoji setting to match these changes.
Add an "Insert Emoji" item to the context menu in entries.
We also add a show-emoji-icon property, which when set to
TRUE, will add an icon that can be clicked to bring up
the Emoji chooser.
When the popover is dismissed, we return the focus to
where it came from. However, by using gtk_widget_grab_focus,
we were messing up the selection if that widget happens to
be an entry. Special-case GtkEntry and use
gtk_entry_grab_focus_without_selecting to avoid this issue.
The json file is imported from the (MIT-licensed) emoji.json[0] node
module, which generates it from the emoji list published by the
Unicode Consortium.
This commit also adds a little tool to convert the data into
a compact GVariant, and the result of that conversion, which is
added to libgtk as a resource. The following commits will make use
of it.
[0] https://github.com/amio/emoji.json
menu margins have been added has a hack to mitigate bug:
https://bugzilla.gnome.org/show_bug.cgi?id=591258 with gtk+4 this
doesn't work anymore on gtk+4, the margin should probably be moved
to the parent window node, but it's not selectable, commenting out
for now.
Since gtk+ draws more than the widget and allocates more size to it than
it knows about, this flag doesn't work anymore. Removing it (or setting
it to TRUE for widgets that used to set it to FALSE) fixes drawing
invalidation when these widgets get allocated a new size.
In gtk_container_real_set_focus_child(), we try to scroll to the
position of the new :focus-child if we have h or v adjustments.
gtk_widget_translate_coordinates() returns FALSE if neither widget is
realized or in other situations that cause output parameters x and y not
to be set. Thus, if the caller did not initialise x/y and uses them even
if the function returned FALSE, they are using uninitialised variables.
In gtk_container_real_set_focus_child(), we did not check the return
value but merrily went ahead and used x and y regardless. This is UB, as
revealed by Valgrind, as well as being pointless.
The trivial fix is to exit early if (!gtk_widget_translate_coordinates).
https://bugzilla.gnome.org/show_bug.cgi?id=776909
Commit 885bcd9fe4 trampled the bit here
that is meant to translate between the nominated focus child and the
actual innermost one that is used for updating the h/v adjustments.
So, we need to save the passed focus child before diving into its
children, then translate and get allocations between them both. This
makes GTK+ 4 behave like GTK+ 3 again: instead of priv->focus_child and
focus_child, we now have focus_child and child, serving the roles of the
nominated focus child and its innermost focus child respectively.
This also ditches the unnecessary call to Widget:get_focus_child(), as
Container::set_focus_child() gets that same new child as an argument.
process-stop-symbolic is unintuitive if represented as a stop sign as in
Adwaita, and completely ambiguous if represented as a cross like the
window close button in other icon themes.
Instead, use application-x-executable, which is already used elsewhere
as a fallback if no specific icon can be found for the application.
https://bugzilla.gnome.org/show_bug.cgi?id=784624
