It seems that alternate implementations of GtkFileChooserWidget
never materialized. The split between GtkFileChooserWidget and
GtkFileChooserDefault is awkward. The immediate problem is that
it makes it difficult to document the keybinding signals. So it
makes sense to drop the abstraction and just have one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=723157
The color chooser test is constantly running into the
problem that the custom color setting is not empty.
Avoid that by using the memory settings backend.
It would be nicer if we could have the tests specify what environment
their expected output was created in, then we could test multiple
scenarios. For now, just fix the setting to avoid test failures.
Stop trying to deal with "theoretical possibilities".
We can't possibly continue to be a faithful GActionGroup implementation
across dispose because dispose has a side effect of removing everyone's
signal handlers.
The code that we ran after the dispose chainup to do all of the fancy
signal emulation was therefore dead. The test that aimed to verify this
was buggy itself due to an uninitialised variable, so really, it never
worked at all.
We keep the re-ordering of the chainup from the original commit to avoid having
trouble with GtkActionMuxer and keep the checks in place that will prevent an
outright segfault in the case that someone else tries to use the interface
post-dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=722189
The signal callbacks are defined to take pointers as their arguments, but the
callbacks found in testsuite/gtk/builder.c are passing a GParamSpec by value
as the second argument. This confuses and angers the compiler on ppc64el,
resulting in segfaults after return from the function due to stack-smashing
by the (completely-unused) argument.
https://bugzilla.gnome.org/show_bug.cgi?id=721700
Improve the color swatch accessible to set a proper role
depending on whether the swatch is selectable or not, and
set the checked atk state when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=721048
And update the colorchooser a11y test to a) use GtkColorChooser
instead of the deprecated GtkColorSelection and b) match this
change. Pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=721045
This commit makes the label accessible implement AtkHypertext,
which returns a AtkHyperlink object for each link in the text.
At the same time, add AtkHyperlinkImpl objects as children
to the label accessible.
Also some private API to indicate that links have changed, and
call that from GtkLabel when needed.
Adjust expected output of the affected a11y tests.
https://bugzilla.gnome.org/show_bug.cgi?id=721410https://bugzilla.gnome.org/show_bug.cgi?id=721421
The button now claims its menu as a child for a11y purposes,
which makes it possible for ATs to see it when the navigate
the tree top-down.
Update the a11y test to match.
Make sure that the tests don't access the host's session bus or
installed gsettings schemas.
Also disable tests for some classes that leak a connection to the
session bus.
https://bugzilla.gnome.org/show_bug.cgi?id=711715
Ignore the "show-desktop" property on GtkPlacesSidebar for the
defaultvalue test.
Currently, "make check" is passing because it runs the test under a xvfb
with no XSETTINGS provider, so we see the Gtk default value. No matter
what we set the default value to in Gtk, however, there will be some
desktop environment in which someone running the installed test outside
of an xvfb will get the wrong result. Best to ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
When downscaling images, Cairo apparently uses algorithms different
enough to make this test trip over. So add the downscaled image as the
reference instead of downscaling the previous reference image.
Fixes the border-image reftest. For real now.
The new downscaling code in Cairo doesn't allow this test, so we remove
the CSS that made the border downscaled.
So the test does test less now, but it still tests the repeat modes of
border images.
One requirement of .ui files is that each object must have an ID,
even if it is never referred to or directly loaded from the code.
This makes editing .ui files much more onerous than it has to be,
due to the frequent need to invent new IDs, while avoiding
clashes.
This commit makes IDs optional in the XML. They only need to
be provided for objects which are referred to or explictly loaded
from the code. Since GtkBuilder needs IDs for its own internal
accounting, we create IDs of the form ___object_N___ if not
specified in the XML.
https://bugzilla.gnome.org/show_bug.cgi?id=712553
So far, this is just supposed to be gdk_cairo_set_source_pixbuf().
Note that this is usually not an API guarantee but courtesy to
applications that used these APIs without a gtk_init() call.
https://bugzilla.gnome.org/show_bug.cgi?id=708547
The headerbar test and the buttons tests changed because we've
recently changed accessible names, descriptions and roles of
GtkHeaderBar and GtkSwitch.
This reverts commit 7cecc8e524.
It is impossible to use the selection object of the menu while it is
collapsed (collapsed menus deselect everything for a start), so even
though the original patch was correct, the followup issues are too big
to solve this quickly to a release.
https://bugzilla.gnome.org/show_bug.cgi?id=707786
It tests gtk_text_buffer_paste_clipboard(),
gtk_text_buffer_copy_clipboard() and gtk_text_buffer_cut_clipboard() in
various situations, including when GtkTextTags are applied to the
selection.
The last test didn't pass.
https://bugzilla.gnome.org/show_bug.cgi?id=339539
nth-child() is 1-indexed, not 0-indexed.
It doesn't matter for this test really, but better do it right to not confuse
poor developers who wonder why the first image is highlighted when nth-child(0)
clearly states "none".
The reftest is a bit flaky because it compares cell renderers with
GtkImage and therefor an icon view with a GtkBox, but it's the best I
can come up with.
https://bugzilla.gnome.org/show_bug.cgi?id=702423
The fix for child properties made the a11y dump for the assistant
case change. After close inspection, the new output is what the
code intends to produce, so update the expected result.
This value is highly sensitive to changes in the theme; we
don't want to have to tweak hardcoded integers in this test case
every time we rev gnome-themes-standard.
Future iterations could do more heuristic matching, but this
is enough for now.
https://bugzilla.gnome.org/show_bug.cgi?id=704747
