This adds a new test which can be scripted to trigger various
event and action sequences, and record state changes in the
accessibility layer.
So far, there are a few tests verifying state changes when
focus changes.
Related to https://bugzilla.gnome.org/show_bug.cgi?id=715176
This utility would likely be useful for Windows builds of GTK+, given the
reasons Alex cited for coming up with this utility[1], and MSVC build
support for librsvg is not available at this time (possible, but not
implemented yet).
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=730450
In bug 733773, gtk-win32.rc was removed from the dist in the attempt to
make the print dialog on Windows themed, so this script was added so that
the gtk-win32.rc file can be generated during the Visual Studio builds of
GTK+ from the autotools scripts. This is also intended for filling in the
arch of the build for MSVC builds for the manifest that is also required
for fixing bug 733773. Python is used as it is already needed for
This is done as a custom build rule in the Visual Studio projects so that
it is easy to clean and rebuild gtk-win32.rc upon an update.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
Rows are not necessarily selected via select_row_internal(), add
the missing signal emissions there. Also the signal should be emitted
when removing the selection altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=729809
This counterpart to gtk_application_get_accels_for_action() lets you
find out if a particular accelerator has one or more actions associated
with it. This might be useful from an accelerator editor or plugin
system to prevent the the installation of conflicting accelerators.
https://bugzilla.gnome.org/show_bug.cgi?id=721367
Currently, jhbuild-ing GTK+ on Ubuntu 14.04 LTS and gcc 4.8.2 errors out with
/usr/bin/ld: encodesymbolic.o: undefined reference to symbol 'g_file_new_for_path'
/opt/gnome/lib/libgio-2.0.so.0: error adding symbols: DSO missing from command line
when trying to build gtk-encode-symbolic-svg. This is because $(GTK_DEP_LIBS) isn't defined in $(gtk_encode_symbolic_svg_LDADD) in gtk/Makefile.am. This patch should fix that.
Thanks to b4n and gregier in irc.gimp.net/#gtk+ for help.
https://bugzilla.gnome.org/show_bug.cgi?id=734201
An animation may be scheduled while the textview content changed in size, so the resize
queued would just unset the animation and set the adjusments with a current value,
defeating gtk_text_view_scroll_to_iter(). In this case, just avoid the adjustment change,
as there is a target value on the way.
https://bugzilla.gnome.org/show_bug.cgi?id=733406
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.
