Re: GtkBuilder partial tree construction

[Murray Cumming <murrayc murrayc com>]

On Tue, 2007-06-26 at 11:08 -0300, Johan Dahlin wrote:
> 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.

That's a little pedantic. libglade is today's way of doing runtime
instantiation from XML and is very tightly associated with GTK+. When
GtkBuilder ships, libglade will be effectively deprecated. So if
GtkBuilder lacks something that libglade has, then that will be
perceived as a regression.

> 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.

As I understand it, file seeks and file reading are greater slowdowns
than processor work. But more I'm not the best person to judge this.

Will GtkBuilder be able to cache its files to prevent repeated parsing.
libglade doesn't do this, I think, but it would be nice.

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

Let's establish that they are bad first. So far it just sounds like you
are trying to justify what is currently difficult to fix.

I'm sounding harsh again. Sorry.

> > 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.

Again, in the time between 2.12 and 2.14 "applications and tools will be
adapted to use split-up files".

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com