`gtk_builder_get_parameters()` is a hot path, being called twice for
each object in each UI file in an application. The majority of objects
have ≤ 8 properties, which are each filtered into either `parameters` or
`filtered_parameters`.
Unfortunately, both of those arrays are created as empty `GArray`s, and
adding 8 elements to an empty `GArray` hits the worst possible case of
reallocating and `memcpy()`ing the array 3 times. As the array size is
doubled with each reallocation, the cost is not particularly well
amortised when the array size is small.
From the `ObjectInfo`, we actually know how many properties there are in
total, so just allocate the arrays at the right size to begin with.
This saves 7% of the instruction cycles needed to start up
gnome-software to the point where it’s showing its main window,
according to callgrind. gnome-software is making around 5500 calls to
`gtk_builder_get_parameters()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We're potentially applying multiple properties during object
construction; we should avoid constantly notifying after setting each
one, and instead coalesce the notifications at the end. In most cases,
the calling code doesn't have access to the instance, so it won't be
able to connect to the "notify" signal anyway, but it avoids a lot of
busy work.
GLib has deprecated GParameter and g_object_newv(); until we switch to
the new g_object_new_with_properties() API, and bump GLib required
version, we should simply ignore the compiler warnings.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
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.
g_utf8_get_char_validated() may return -1 or -2
return type is gunichar(guint32)
Therefore such checks like 'gunichar < 0' or 'gunichar > 0'
are always 'false' or 'true'(except when gunichar == 0).
Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
https://bugzilla.gnome.org/show_bug.cgi?id=742774
These turned out to break existing ui files, concretely
GWeatherLocationEntry was no longer guessed correctly.
Update the testcases to reflect this, and add a testcase
for GWeather.
Factor out the typename-to-get-type mangling as a separate
function, for easier testing.
Also fix some cases where it doesn't, currently, like
GString -> g_string_get_type and
GdkRGB -> gdk_rgb_get_type
Just calling get_type() does not ensure that the signals, properties
and everything else gets set up properly. Ensure it is, by calling
g_type_class_ref() before using the type. This fixes the testcase
added in the previous commit.
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"
