[Glade-devel] latest commits + remove GladeWidget->children
- From: bighead users sourceforge net (Archit Baweja)
- Subject: [Glade-devel] latest commits + remove GladeWidget->children
- Date: 21 Aug 2003 01:15:16 +0530
Hi
Paolo Borelli <pborelli katamail com> writes:
Hi,
this afternoon I committed a couple of patches which add icons to the
entries in the project view (used in the main window and in the widget
tree) and in the clipboard view.
Beside in the clipboard view I switched from a GtkTreeStore to a
GtkListStore: as a matter of fact in the clipboard view we (and glade2
does the same) just list the widgets on the clipboard without having a
tree of their childrens. Note that the populate_model[_real] had some
code for adding children, but that was never triggered because was
inside an always false condition.
Well we had kept it so that if need be in the future they ask us to show
children in the clipboard-view, we can just set "add_children" paramter to
true. But since we don't need it, its nice to get rid of that code.
A nice side effect of this last change is that the ->children field of
GladeWidget is not used anywhere anymore (exception made for a couple of
places where ->children is assigned and that can obvoiusly go away): so
my next step is to get rid of ->children in GladeWidget.
Even if the code impact of this change is small I would like to have
"green light" signal before going on, since it is a design issue: as a
matter of fact I think that originally the tree structure in GladeWidget
(formed by ->parent and ->children) was considered as the main structure
to map the hierachy of the created GUI and of the xml file.
However this information is redundant since Gtk already has a tree
structure (each gtkWidget has parent and, if it is a container,
children) and in fact we already use that internal tree to write the
.glade file.
Hmm didn't know that.
IMHO keeping this additional tree structure is just a pain since it must
be kept in sync with the gtk intenal one (see reparenting in
glade_project_add/remove).
I agree. No point in keeping that extra structure (if it doesn't keep any
additional info besides what Gtk+ does for us).
Once GladeWidget->children is gone, GladeWidget->parent should be easy
to kill: introducing a glade_widget_get_parent function which works as
glade_placeholder_get_parent should do.
/me holds up green flag.
Archit
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]