After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575714 - gtk_builder_add_objects_from_file() broken for adjustments
gtk_builder_add_objects_from_file() broken for adjustments
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Class: GtkBuilder
2.16.x
Other Linux
: Normal major
: ---
Assigned To: GtkBuilder maintainers
GtkBuilder maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-17 16:00 UTC by Murray Cumming
Modified: 2015-04-29 19:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Murray Cumming 2009-03-17 16:00:05 UTC
When using gtk_builder_add_objects_from_file(), specifying a single top-level object, a child widget might need an extra non-UI object, but GtkBuilder then has no access to it, and complains like so, while not setting the wanted property values:

Gtk-WARNING **: No object called: adjustment2


For instance, a GtkSpinButton might be defined like this:

  <object class="GtkSpinButton" id="spinbutton_format_text_multiline_height">
    <property name="visible">True</property>
    <property name="can_focus">True</property>
    <property name="adjustment">adjustment2</property>
    <property name="climb_rate">1</property>
    <property name="numeric">True</property>
  </object>

But that adjustment2 is a different _top-level_ object such as this:
  <object class="GtkAdjustment" id="adjustment2">
    <property name="value">3</property>
    <property name="upper">100</property>
    <property name="step_increment">1</property>
    <property name="page_increment">10</property>
    <property name="page_size">10</property>
  </object>

I think GtkBuilder should find and use that extra top-level object instead of complaining. I shouldn't have to manually specify its name to gtk_builder_add_objects_from_file() as well as the name of the top-level object that I actually care about. 

This use of extra top-level objects for adjustments and suchlike seems to be new in recent versions of glade-3 and/or GtkBuilder.
Comment 1 Johan (not receiving bugmail) Dahlin 2009-05-11 12:50:13 UTC
You will need to specify all top-level objects required to build an interface to gtk_builder_add_objects_from_file(), it is documented already.
 
Add objects from file is not the same as the root argument in libglade, it allows you to cherry-pick objects, not subtrees w/ their dependencies.

See bug 447998 for the complete rationale.
Comment 2 Murray Cumming 2009-05-12 10:04:22 UTC
Then for me this is a regression compared to libglade (which GtkBuilder replaces). And I believe that this function was added to solve that regression.

These extra top-level objects are not something that the application should even need to know about, and the application coder generally doesn't notice that they have been created (and linked) when using Glade.

Maybe you'd like the bug report to be phrased or titled differently but this is still a bug.
Comment 3 Tristan Van Berkom 2009-05-12 15:56:21 UTC
Note for this as well GtkBuilder will have to remember
which UIs were added probably in a per descriptor list
or such (where you have one descriptor per call to
_add_from_file()), GtkBuilder will also have to recognize
that the same file was used to add new objects to the UI,
and it will have to be clear when GtkBuilder parses
the same UI twice for separate objects, whether GtkBuilder
needs to recreate new objects for the refferences in
the Glade file, or if those refferences are meant to be
shared throughout the UI, we may have to either decide
on a behaviour there, or introduce something in the
format to denote ownership of a reffered object (i.e.
references with ownership are always created, otherwise
they are created once and only on demand).

Also agree, regardless of it being documented to have
a somewhat flawed behavior - we should still keep a
bug open for the sake of improvement (whether this is
a regression is speculative - libglade didnt build 
non-widget objects; but that also doesnt mean this 
is not a bug).
Comment 4 Radosław Szkodziński 2010-03-26 12:34:39 UTC
Is there any motion to fix this?

Another bad behavior is that the objects bound to the adjustment don't have their values set properly. (everything else is all right)
Or should I report it as another bug?

GTK+ 2.18.7, Glade 3.6.7
Comment 5 Radosław Szkodziński 2010-03-26 12:37:26 UTC
Sorry for spam, it's bug 494329 I think.
Comment 6 Murray Cumming 2010-03-26 13:06:21 UTC
I noticed that recent versions of Glade don't add top-level adjustments when the defaults would be enough, so this is slightly less annoying now.
Comment 7 Matthias Clasen 2015-04-29 19:24:50 UTC
I don't think this is going to change at this point.