We were only applying <binding> elements when the
object is constructed, which can be triggered by
various things (e.g. a <style> element). Defer
this until we reach </object>, so we can be sure
that we pick up all the bindings.
Testcase included.
Fixes: #4147
The GtkBuilder parser constructs the object e.g.
when handling a <binding> element. There may be
more <property> elements after it, which we were
just not applying. Fix that by always applying
property when we see </object>. To do that, we
need to track the applied status per property.
Test included.
Fixes: #4208
... and use it. This function looks up an object like
gtk_builder_get_object() but generates an error on failure.
Unlike the evil function _gtk_builder_lookup_object() which also
generates an error but hides it for later lookup.
Use this to avoid continuing applying properties when an error was
encountered.
- Propagate the error back to the parser, so we get a proper GError
instead of a g_warning().
- Connect closures by id, don't construct a name from the ids so that
glib can take it apart again.
This currenly just wraps GMarkupParser, but the plan is to expose this
instead of GMarkup in the GtkBuildable interfaces, allowing us to
replace the parser with something that handles pre-parsed input
instead.
Note that we duplicate some of the features of GMarkup to implement
the APIs rather then call down to GMarkup, as we need to support these
in the pre-parsed case anyway.
In addition to <property name="foo">bar</property> referring
to an object with ID bar, we now also parse
<property name="foo"><object>...
to specify a property 'inline'.
Add a convenience function that is like gtk_builder_get_object()
but stashes away a GError if a lookup fails. To make the error
message informative, the function takes a line/column pair.
Doing things this way is necessary because the custom_tag_end,
custom_finished, and parser_finished vfuncs don't take a
GError parameter, despite being called from a place where
we can report a GError back.
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"
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
Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=699016
The fix here is slightly different. We make
_gtk_builder_parser_translate return a const char * instead of
a dup'ed string, and fix up the callers.
This adds the definition of the <template> tag with some documentation
on the variant of the format.
_gtk_builder_extend_with_template() is to be used while GtkContainer
builds from composite templates. A couple of error codes are also added
to handle a few new possible failure cases.
DTD Files gtkbuilder.rnc and gtkbuilder.rng have been updated to include
the new <template> tag and it's attributes.
Change the format of GtkBuilder <menu> to be more in-line with the style
of the rest of GtkBuilder so that we can do translation in a consistent
way.
The format is now substantially more difficult to hand-write, but tools
should be along soon.
There is an xslt program attached to the bug to help you convert your
existing .ui files from the old format to the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=668696
There are new calls to load ui files from resources, and
you can now read pixbufs by using relative paths in a ui
file read from a resource, or by using absolute resource:/// uris.
This makes GtkBuilder accept a GMenuMarkup tree at the toplevel
(ie with <menu id='foo'> being a child of <interface>) and the resulting
GMenu object can be obtained via gtk_builder_get_object (builder, "foo").
