We were missing all of the status directories, and a few sizes.
This was causing us to not find image-missing on systems without
hicolor icon theme (this basically only happens on Windows).
https://bugzilla.gnome.org/show_bug.cgi?id=764378
e8aa9b0440 introduced a new debug mode
that highlights resizes. Unfortunately it has the side effect of
always queueing redraws even when the debug mode is not enabled.
Make the redraw conditional.
While this commit was found to make emacs windows shrink (and it was
reverted in the gtk-3-20 branch for that reason), that was the only
observed breakage, while the reversal broke several of our unit tests.
Closer study of the emacs sources revealed that it does some really
unsupportable things like doing its own X event handling behind GTK+'s
back and freely mixing sizes of GtkWindows and GdkWindows obtained in
various ways. I've filed a bug against emacs with suggestions for how
to avoid the shrinking window, regardless of this commit.
Original commit message:
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Since we are really only interested in the center point of the
slider allocation, the pre-computed slider geometry is perfectly
fine, just use it always. This avoids the complication with
gadget visibility.
The slider gadget may be turned invisible as side-effect of
gtk_range_calc_slider(). If that happens,
gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
which leads us to calculate a negative allocation for the highlight
node. Avoid this, by just reusing our already calculated slider
allocation in this case (it is not technically the same as the
content, allocation, but the difference hardly matter here.
https://bugzilla.gnome.org/show_bug.cgi?id=764022
As the elements in the enum are not explicitly numbered, inserting an
element between some other elements shall change the values of elements
after the insertion. So append the new element at the end.
Anyway, no code should rely on the position of an element in an enum.
https://bugzilla.gnome.org/show_bug.cgi?id=763850
Some other widget might have mapped and raised another child window of
the toplevel in the meantime, causing the popover window to be covered.
Raise the popover window to avoid the issue.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763627
The trash is monitored for state changes - going from empty to non-empty and the
other way round. Monitoring is done by handling change signals from a regular
file monitor. On each signal, an enumeration of the trash contents is started in
order to see if it is empty or not. This causes issues when many files are
trashed, because the gvfs trash backend is flooded with enumeration requests,
resulting in CPU usage spikes. In order to fix this, the "item-count" attribute
of the trash should be queried instead.
Replace asynchronous enumeration with asynchronous information query and update
the trash state based on the "item-count" attribute. Emit state change signal
only when the state actually changes.
https://bugzilla.gnome.org/show_bug.cgi?id=763600
When loading a per-theme settings.ini file, look for it in
the same directory where we found the gtk.css file for the
theme. Previously, we were always looking in
$prefix/share/themes/THEME/gtk-3.0/, even if the css was
loaded from somewhere else.
https://bugzilla.gnome.org/show_bug.cgi?id=641354
With this change, we now look in
$XDG_DATA_HOME/themes/THEME/gtk-3.x
$HOME/.themes/THEME/gtk-3.x
$XDG_DATA_DIRS/themes/THEME/gtk-3.x
GTK_DATA_PREFIX/themes/THEME/gtk-3.x
https://bugzilla.gnome.org/show_bug.cgi?id=641354
