The port is kind of evil, in that it stores either a PangoFontFamily or a
PangoFontFace in the list, depending on if the fontchooser is configured
to select fonts or faces.
It also does not cache the font description anymore, so more calls to
pango_font_describe() may happen.
If both of these issues turn out problematic, the fontchooser would need
to resurrect GtkDelayedFontDescription again and put objects of that
type through the model.
These changes depend on Pango 1.46's introduction of listmodels and
various new getters, so the dependency has been upgraded.
After the :can-focus change in the previous commit, widgets
need to set suitable focus and grab_focus implementations
to implement the desired focus behavior.
This commit does that for all widgets.
1. Rename the thing
2. Turn it from a signal to a vfunc
3. Pass the GtkCssStyleChange to it
We don't export any public API about the GtkCssStyleChange yet, it's
just a boring opaque struct.
The FileChooser ToolKit (fctk) had its own machinery to handle default
sizes which was completely busted and trying to marshal random numbers
through the widget hierarchy that maybe made sense in 2012 but don't do
now.
Get rid of it, just keep the dialog's GSetting - which funnily enough
used to be written by the dialog but written by the widget.
But that's fctk for you.
The treeview is evil and keeps reference cycles in the
form of various tree row references. That gets cleaned up
if you explicitly gtk_widget_destroy the treeview. But since
07f2024bfc, the scrolled window no longer destroys
its child, exposing this issue as a reference leak in
the objects-finalize test.
The font chooser widget is affected here because it calls
gtk_tree_view_scroll_to_path from init(), which creates one
of those reference cycles. Work around this in the font
chooser by unsetting the tree view model in dispose, which
clears up this cycle.
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
HarfBuzz 2.0 deprecated some API used by the GtkFontChooser, but since
we're still supporting older versions of HarfBuzz, we should disable the
deprecation warnings to avoid too much noise during builds.
Use an event controller on GtkFontChooserDialog, a nice side effect
is that we can use gtk_event_controller_key_forward() and
gtk_search_entry_set_key_capture_widget() instead of passing events
around for dialog search.
This is meant as an input to the font chooser.
We don't want the user to select a language, but
rather have fonts presented as they would work for
the current language. Therefore, do away with the
lang/script combo on the tweak page.
Really exclude the portions in the gtkfontchooserwidget.c that are built
when HarfBuzz and PangoFT2 are built, and update the Meson files to
exclude such sources as well from the main GTK SO/DLL and from the
gtk4-demo program.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
For some font features, we can figure out affected
glyphs, and show before/after. For some others, we
hardcode typical sequences.
Still to do: figure out how to find ligatures and
show them.
Turn the GtkFontChooserLevel field into flags, and
add flags for OpenType variations and features. The
motivation for this is to make font-features in the UI
opt-in, since applications need to support them by
applying the pango attribute.
This is an automated change doing these command:
git sed -f g gtk_widget_set_has_window gtk_widget_set_has_surface
git sed -f g gtk_widget_get_has_window gtk_widget_get_has_surface
git sed -f g gtk_widget_set_parent_window gtk_widget_set_parent_surface
git sed -f g gtk_widget_get_parent_window gtk_widget_get_parent_surface
git sed -f g gtk_widget_set_window gtk_widget_set_surface
git sed -f g gtk_widget_get_window gtk_widget_get_surface
git sed -f g gtk_widget_register_window gtk_widget_register_surface
git sed -f g gtk_widget_unregister_window gtk_widget_unregister_surface
git checkout NEWS*
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
