Re: GtkBuilder partial tree construction

[Johan Dahlin <jdahlin async com br>]

Murray Cumming wrote:
> On Tue, 2007-06-26 at 10:42 -0300, Johan Dahlin wrote:
>> Murray Cumming wrote:
>>> On Tue, 2007-06-26 at 14:19 +0300, Kalle Vahlman wrote:
>>>> 2007/6/26, Murray Cumming <murrayc murrayc com>:
>>>>> libglade's _new() function has a "root" parameter:
>>>>> http://developer.gnome.org/doc/API/libglade/gladexml.html#GLADE-XML-NEW
>>>>>
>>>>> This is necessary because libglade otherwise instantiates all the items
>>>>> in the file. Does GtkBuilder instead only instantiate the objects when
>>>>> you actually use gtk_builder_get_object()?
>>>> See bug 447998 for discussion on this:
>>>>
>>>>   http://bugzilla.gnome.org/show_bug.cgi?id=447998
>>>>
>>>> but in short: no, it instantiates them as a part of the
>>>> parsing/building process and it's not going to be easy to do it
>>>> properly otherwise.
>>> OK, so we need to have one file per window, which the glade-3 developers
>>> might not be so happy about. I guess, the gtk-builder-convert script
>>> should be changed to create lots of individual files.
>> I'd like to support partial construction of object trees, but as Kalle
>> pointed out, it's very complicated given how the xml parser of GtkBuilder
>> is implemented.
> 
> If we (erm, you, I suppose) don't manage to fix this regression
> (compared to libglade), and allow this API be shipped with GTK+ 2.12,
> then while we are waiting for GTK+ 2.14, applications and tools will be
> adapted to use split-up files, and we could have years of performance
> problems due to lots of little files.

I do not consider this as a regression since Gtk+ has never shipped an
interface builder before.

You're exaggerating about the performance problems. One extra file per
constructed, user visible interface is not going to be a bottleneck in your
application. Splitting up interfaces into several files is likely to be
faster, since you don't have to parse a large xml file once for
each interface you want to construct.

So turning the question around, do we really want encourage bad (from a
performance perspective) practices introduced by libglade?

> So I think this should be a blocker. I'd rather revert GtkBuilder than
> ship it with this bug. Sorry to sound harsh. I just want suggest how we
> can have quality without delays, if necessary.

An API allowing this can easily be added to a future release.

-- 
Johan Dahlin <jdahlin async com br>
Async Open Source