Popovers may get relocations optimized away if only x/y changed
in the GtkAllocation. So make sure the toplevel updates popover
positions on all situations.
https://bugzilla.gnome.org/show_bug.cgi?id=729140
It is bad if the image that is used as a fallback for missing
images goes missing itself, so include it as a resource. This
way, it will always be available.
The rules-hint property has always been a fairly bad application API, as
it set some wrong expectations for the developers; deferring to the
theme makes it impossible to design application reliably, and if this is
a usability setting we should either impose this setting on every theme,
or simply drop it.
Our own default theme does not honour the zebra striping, which makes
this function even more questionable.
In practice, usability studies on zebra striping have demonstrated that
alternating colors on a list it improves readability just as much as
clear ruling between rows, or by visually differentiating the selected
row. Zebra striping improves readability (or, at least, it does not
hinder it) on static displays, like a table on paper or a document; on a
dynamic display, like an application's UI, there are different
strategies that yield similar, if not better, results.
https://bugzilla.gnome.org/show_bug.cgi?id=733312
The next call to gtk_list_box_get_selection_mode just expected the
GtkListBoxRow's parent to be a GtkListBox and failed when the row was
added to something other than a GtkListBox.
https://bugzilla.gnome.org/show_bug.cgi?id=733782
If an icon theme has a file called "foo-symbolic.symbolic.png" which
was converted from svg using gtk-encode-symbolic-svg we will read
it in an recolor, allowing symbolic icons without using librsvg.
https://bugzilla.gnome.org/show_bug.cgi?id=730450
If the same position is requested on a popover, it should at least ensure
the window is realized and raised, even if no resizes are queued on the
content. Otherwise other widgets being mapped might raise the windows over
the popover's if its original position is unchanged.
https://bugzilla.gnome.org/show_bug.cgi?id=734129
It turns out that when we were painting the shadows, we painted the them
with the base color once, which contained the alpha, and then blurred it
and used it as a mask for the fill, which has the fill again.
To fix this, always paint the base surface with full alpha. The existing
code applies the blur conditionally sometimes in weird ways, so the code
shuffling fix may not look correct, but be assured it is. If the blur
happens, the new cr we return has the *default* color applied, which is
fully opaque black, which works perfectly against the A8 surface.
The fallback spinner code needs some modification, since it is
intentionally using the alpha to paint the lobes which are "in the past".
Since we shouldn't be hitting this fallback path very often, we use a
temporary group and paint it with paint_with_alpha, even though it is
slow.
Introduce a new debug category "actions" and write some messages from
GtkActionHelper about if we can find the actions or not.
We will probably soon want to add some similar messages to
GtkMenuTrackerItem.
https://bugzilla.gnome.org/show_bug.cgi?id=733965
X11 backend doesn't, and for good reason - main code body does not check
that the window it sets opacity for is, in fact, toplevel.
Just silently fail to do anything for non-toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=733769
This leads to an assertion failure, because parent window is never registered
in the first place, widget's own GdkWindow is. But that window is unregistered
in a generic fashion by GtkWidget code, so there's nothing for us to do here.
https://bugzilla.gnome.org/show_bug.cgi?id=733766
Instead of slavishly following the naming spec, group the icons
into categories that are more likely to be useful for application
developers. Based on input from Allan Day and Jakup Steiner.
So far, gtk_window_set_focus just did not work when called on
a hidden window. Change it to record the desired focus widget
for hidden windows, and apply it when the window gets shown.
This is similar to how we tread other window properties that
can't be set before the window is realized, like maximized
or fullscreen.
This is related to
https://bugzilla.gnome.org/show_bug.cgi?id=734033
The previous code for computing the clip rectangle forgot to respect
the text-shadow CSS property. This is usually not very visible because
text shadows usually don't extend the ink rectangle by very much.
See attached testcase for an example.
Support environment variable GDK_WIN32_FONT_RESOLUTION that can be set to
a desired dpi (72, 96, 130, etc) to override system settings. Useful for
debugging, since changing system font scaling requires the user to log off
and log on again.
https://bugzilla.gnome.org/show_bug.cgi?id=734038
Although there is the "changed" signal, it is more correct to notify the
"text" property too. It can be useful for a small text view, where the
text is saved e.g. to gsettings with a binding to the text property.
The "text" property includes only the text, not child widgets or images,
so the notify signal is sent too many times (also for child widgets and
images), but it's not a big problem.
https://bugzilla.gnome.org/show_bug.cgi?id=624791
