We were previously mixing the model used when filtering with an iter that
has been resolved to the backing model.
This results in both an invalid row index as well as an invalid
iter->stamp.
Previously, we would pango_font_describe() every time the code ran and
we wouldn't ever hit the optimized quick exit.
The code now is a lot more complex because the
compute-actual-value-when-required-the-first-time approach is not
supported out of the box in GtkTreeModel (or GValue).
We can't add properties to the interface, since it breaks
3rd party implementations of the GtkFontChooser interface.
These exist, for example in gnumeric.
So, instead of a new property, add getter/setter vfuncs.
The font chooser delays creating the font description from the font face
as long as possible (it's slow). Because we use fixed height mode, we
only have to create font descriptions for rows we are actually going to
show.
This was achieved by looking at the font description column and if it
was NULL, we created a font description and gtk_list_stiore_set() it.
Unfortunately this caused a "row-changed" signal to be emitted and this
emission could happen during the cell data func.
And that caused infinite loops with accessibility when you were unlucky.
This change replaces the NULL font description with an empty one and
instead of setting the correct font description, we
pango_font_description_merge() it in. This way, the list store doesn't
change and no signals are emitted.
https://bugzilla.redhat.com/show_bug.cgi?id=1197267
We were relying on indirectly getting notify when fontconfig
configuration changes, by GtkSettings translating the timestamp
change into a style-invalidation, which gets fed through the
css invalidation machinery. That machinery has gotten good enough
at optimizing away redundant changes that it no longer emits
::style-updated in this case.
So, instead make the font chooser listen directly to what it
cares about: the fontconfig change notification from GtkSettings.
We can use the GtkSettings:gtk-fontconfig-timestamp property to decide
whether or not we should reload fonts on style and screen changes. This
should avoid doing a lot of work with large font collections when only
the theme has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=748782
Commit 30a1c4ab fixed several memleaks including one in
gtk_font_chooser_widget_find_font.
However, the fix causes one extra call to gtk_tree_model_iter_next()
after finding the font we look for (ie pango_font_description_equal
returns TRUE): the 'increment' part of the for loop
(gtk_tree_model_iter_next) is run before the 'exit condition' of the for
loop is evaluated.
This commit reverts this part of commit 30a1c4ab and adds an extra
call to pango_font_description_free in order to fix the leak.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
When using GtkFontChooserButton, the same GtkFontChooserWidget can be
hidden and shown multiple times. When doing that, the font that was
chosen the previous time should be the selected one in the
GtkFontChooserWidget, however this does not work as expected and a
somehow 'random' font gets selected (or none) instead.
Every time the font chooser widget is shown, its style will be updated,
causing gtk_font_chooser_widget_style_updated and then
gtk_font_chooser_widget_load_fonts to be called.
gtk_font_chooser_widget_load_fonts starts by clearing the GtkListStore
listing the available fonts, repopulates it, and then makes sure the
current font is selected.
However, this does not work as expected, as during the call to
gtk_list_store_clear, the cursor_changed_cb will be invoked multiple
times when the GtkTreeView cursor gets moved when the line where the
cursor currently is gets removed. This will cause the 'current font'
state (priv->font_desc) to be unexpectedly modified, and when
gtk_font_chooser_widget_load_fonts tries to reposition the cursor to the
'current font', we won't get the expect result.
This commit avoids that by making sure cursor_changed_cb does not get
called when we call gtk_list_store_clear in
gtk_font_chooser_widget_load_fonts.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
Instead of reconstructing a display name from the
PangoFontDescription, use the font family and face
objects, which have the original font. This lets us
get the names of fonts like Noto Sans CJK DemiLight
right, which would be shown as Noto Sans CJK SemiLight
when mangled via PangoFontDescription, since Pango
treats 'DemiLight' as an alias for the SemiLight weight.
https://bugzilla.gnome.org/show_bug.cgi?id=733832
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Using an offset from the struct means you can have children in
both the public and private (via G_PRIVATE_OFFSET) parts of the
instance. It also matches the new private macros nicer.
https://bugzilla.gnome.org/show_bug.cgi?id=702563
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Scroll to the selection when setting it so the selected font is
visible on screen. This is especially useful if an initial font is
set for the user to see it.
https://bugzilla.gnome.org/show_bug.cgi?id=684156
This way, all rows have the same height. It has 3 advantages:
1) No actual computation is necessary to compute the size of the cell.
This speeds up the list tremendously (filling out the list goes from
25s to 3s).
2) Buggy fonts don't mess up the list anymore with their weird sizes.
Instead, they are clipped / empty space is added.
3) Buggy fonts look more buggy. So their use is hopefully discouraged.
With absolute sizes, Pango is way better at getting the actual sizes of
the fonts to match up. It's a bit harder to compute a proper value for
this, whcih makes the code ugly, but as long as it works better...
This way, we can find fonts way quicker as we only need to create font
descriptions for fonts with matching families. Most importantly, we're
rather quick in the "the font doesn't exist" case.
Name it gtk_font_chooser_widget_load_fonts(). Also, don't take any
arguments, they were the same everywhere and they're member variables of
the font chooser anyway.
Instead of reloading the font list, we now just queue a redraw. This
works, because the preview text is added using a cell data func instead
of a custom column.
... which looks up the font in the list of fonts. This then can be used
to select an actual font upon changes.
Also fixes cases where the get_family() and get_face() functions would
return outdated data when set_font() had been called.
They now go through gtk_font_chooser_widget_take_font_desc(). The end
goal is to make all changes go through this function, so that all
updates that are happening are easy to track.
Another change is that the code now merges the font description instead
of just using the new one. This avoids weird situations when people set
the font "Bold" for example, which has neither a size nor a font family.
... instead of rereading all the fonts every time.
With this change, the liststore now contains every font face known to
GTK, so we can actually walk it for matching fonts.
- Don't do unnecessary casts
- Fix weird variable declaration indenting
- Fix loop indentation
- Use a for loop for iterating over a list, instead of a while loop
- Casefold font name only once, instead of every iteration
- Remove needless true_var = true_var && TRUE assignment
The setter for the "font" property returned a boolean that indicated
whether the given font has been found. Instead, fall back to the default
font name when the given font doesn't exist.
GtkFontButton already has a property named "font-name" which may
conflict / be an ABI break when moving GtkFontButton to implement
GtkFontChooser. Also, this is more in line with how other parts in
gtk (e.g. GtkCellRendererText) call a font string property.
Make the GtkFontChooser API similar to the Gtk{File,Recent,App}Chooser
APIs by introducing GtkFontChooser as an interface, that has a default
implementation in GtkFontChooserWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=657627
