Re: GtkBuilder partial tree construction
- From: "Kalle Vahlman" <kalle vahlman gmail com>
- To: "Murray Cumming" <murrayc murrayc com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Johan Dahlin <jdahlin async com br>
- Subject: Re: GtkBuilder partial tree construction
- Date: Tue, 26 Jun 2007 17:34:46 +0300
2007/6/26, Murray Cumming <murrayc murrayc com>:
On Tue, 2007-06-26 at 10:42 -0300, Johan Dahlin wrote:
> 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)
First of all, I seriously doubt that directly comparing each feature
from libglade to GtkBuilder is not useful, since the two differ
already on the concept level. Libglade is quite strictly a widget tree
builder, while GtkBuilder builds objects (which may or may not have
children).
Secondly, while intended to be a replacement, I hardly see why
something added to GTK+ could regress from a third party library. It's
not like libglade will be blown away from ftp servers once GTK+ 2.12
is released. Nor can you even claim that GtkBuilder would suck
developer attention from libglade (since AFAIK it has practically none
;).
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.
As Johan pointed out, this might actually be the reverse. And
according to tests by Mr. Vire (of which he'll be talking more at
GUADEC), on desktop the difference between parsing 1000 lines of xml
and 20000 lines of xml is not really mind-boggling.
Also, how many files would this change really create in a normal use
case? How many files will start to be a problem? If you really are
accessing an UI descripton really often (say, a dialog), loading it
once to a buffer and building the UI with that should suffice, right?
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.
Quality doesn't come without testing, and without stable release there
will not be much testing. So delaying will mostly just mean delaying.
And, as Johan said, adding it later (if possible) won't be a big deal.
> > I am concerned that this makes it impossible to use GtkBuilder to define
> > the properties for a single widget, without instantiating a useless
> > invisible window object. That's a technique that I use currently.
>
> That sounds like a sensible use case.
I just edited the demo.ui from gtk-demo to only contain the treemodel
and the treeview, coded up a little thing that loaded that treeview
and stuffed it inside a window created by hand. Everything seemed to
work fine, so I don't think the invisible window is necessary with
GtkBuilder (is it with libglade?).
--
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]