This test just checks that all the icon names that GTK uses are present
in the default icon theme.
As icon names are not checked programmatically and we do not want to run
into missing-icon icons in the code, this test seems necessary.
For now, it's just a stub that tests stock icons.
To make the icontheme test run successfully when installed,
we need to use the correct test-framework-provided location,
and we need to install the test theme without stripping its
subdirectory structure.
Added GTK_BUILDER_ERROR_INVALID_PROPERTY and GTK_BUILDER_ERROR_INVALID_SIGNAL
error codes
ObjectInfo: Use a GType instead of a char * for the class name.
PropertyInfo: Use a GParamSpec instead of a char * for the property name.
SignalInfo: Use signal id and detail quark instead of a detailed signal name string.
This not only save us a few malloc in each case but lets us simplify the code
and report unknown properties and signals as a parsing error instead of just
printing a warning.
Binding an object sensitive property with a check button active property will look like this:
<object class="GtkButton" id="button">
<property name="sensitive" bind-source="checkbutton" bind-property="active"/>
</object>
This is based on the original work done by Denis Washington for his GSoC project
This closes Bug 654417 "[GSoC] Add <binding> element to GtkBuilder syntax"
- As the tests show, some of the functions have a strange and
inconsistent behavior for corner cases.
- Rename test_full_buffer() -> test_search_full_buffer() because
textiter.c is used for other GtkTextIter unit tests.
https://bugzilla.gnome.org/show_bug.cgi?id=727908
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
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
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
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
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
