This is better than nothing at all. The wording is taken from Carlos's
commit message when he added this shortly before 3.12 (but skip Since).
Skip the bit from his commit message explaining what this replaced; we
don't need to say all the less good things our convenience API replaces.
as per efd3758f6a strcasecmp() is not a C
standard thing (not that we bothered including any header for it anyway)
and so this test failed to build on Windows with Microsoft Visual C.
When we decide to fall back because the settings portal
is not present, adhere to that decision elsewhere. And
treat the fontconfig-timestamp like the other special-cased
settings, with G_TYPE_NONE.
Under Wayland, we are currently directly using GSettings
for desktop settings. But in a sandbox, we may not have
access to dconf, so this may fail. Use the new settings
portal instead.
As GSettings now supports session-specific defaults, GNOME Classic
no longer uses a separate schema and the decoration layout is always
determined by the regular schema.
This essentially reverts commit add67b516c (although the code was
moved since then).
https://gitlab.gnome.org/GNOME/gtk/merge_requests/400
By returning a default surface. The situation where there's no
currentContext arises when GtkCSS is trying to determine the
layout sizes so no actual display is necessary.
Closes: #1411
and use 150 as natural-width.
Currently there's no way for a GtkEntry to be less
than 150px wide (apart from using "width-chars" property),
this is too much for a default minimum-width, an app
developer may need to have a shorter GtkEntry, for example
when the UI it's been shrunk by the user (see [1]) or when
you want to match the size of another widget (which is less
than 150px) see [2] for Evince bug on using
gtk_combo_box_new_with_model_and_entry() for PDF forms where
GtkEntry of ComboBox is too wide and doesn't match the combo
list width.
Using "width-chars" property may be a workaround to obtain
a short minimum-width for the entry, but is not a proper
solution for the mentioned cases as you may not know how
short your GtkEntry will be, or the fact that using "chars"
as a width unit is not pixel accurate.
Curious note: the commit that introduced the GtkEntry
minimum-width to be 150px is from 20 years ago, see
https://bit.ly/2ySEfK4
[1] This change was already suggested by Benjamin Otte
in a blog comment https://bit.ly/2J96wRo
[2] Fixes issue evince#1002
- Selection mode does not get the special devel styling.
- removed teh last-child() selector for it doesn't work anymore.
Better style all section of the headerbar than none. Proper fix pending.
https://source.puri.sm/Librem5/libhandy/issues/57
Instead we just cache the monitor number and get
out of it the nsscreen when it is needed. This is
a requirement since it nsscreen it is not supposed
to be cached.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1312
This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
buildable_add_child() calls set_tab_label(), but the latter did nothing
to update the menu_label corresponding to that tab with the new text.
Using Builder to populate the tab child, only tabs other than last got
the right non-default labels, and even that was mostly coincidental, as
adding the main child called update_labels() via real_insert_page(), so
it took effect when the 2nd last main child is added, updating the rest
but leaving the last with the default label, not that given in Builder.
Fix by factoring out the code from child_reordered() to a new helper
menu_item_recreate() and calling that in set_tab_label(), so that
whenever the tab_label is updated, so is its corresponding menu_label.
This fixes the reported case and presumably others that we could write.
fixes https://gitlab.gnome.org/GNOME/gtk/issues/1397
Comments matched to reassure the compiler that fallthrough is
intentional are supposed to precede the case or default keywords, at
least in GCC, so the one here did not suppress the warning with GCC. We
can just the if condition and put the comment at the end to solve that.
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
This meson port is not upstream yet, so a wrap file is not included.
Upstream has expressed interest but the port hasn't been tested on all
platforms yet. Will be added when it gets upstreamed.
Link to WIP port: https://github.com/centricular/harfbuzz
We do this for every single node, which is a little costly, especially
since the common case for the modelview matrix these days is a simple
translation. So, check whether the new modelview matrix is only a
translation matrix and if so, don't do a full matrix multiplication per
node.
