[Glade-devel] I'm back.

[e98cuenc free fr (Joaquin Cuenca Abela)]

Paolo wrote:
> On Wed, 2003-06-25 at 00:18, Joaquin Cuenca Abela wrote:
> > > The best solution IMHO is to make GladePlaceholder a
> > > GladeWidget and include it in the tree structure instead of 
> >
> > I don't quite agree.  GladePlaceholder is a GtkWidget, so 
> if you want 
> > to also make GladePlaceholder a GladeWidget, then 
> GladeWidget should 
> > also be GtkWidget, and that doesn't makes sense.
> I don't understand why GladeWidget should be a gtkWidget... we have
> GladeWidget->widget which is the actual gtk widget; in my 
> proposal also
> the placeholders have a GladeWidget associated with them where the
> GladeWidget->widget is what the placeholder is now.

Ok, I'm sorry, I misunderstanded your statement.  When you said: "The
best solution IMHO is to make GladePlaceholder a GladeWidget", I though
that you wanted to make GladePlaceholder inherit from GladeWidget.

So, if I understand, your proposal is to create a GladeWidget structure
for each placeholder, just like we do right now with the others
GtkWidgets, isn't it?

That would work, but placeholders really don't need to access any of the
GladeWidgets variables, so adding it just to make them look like a glade
controled widget, to be able to print them feels a bit hacky.  Specially
if you take in account that anyway you should hard-code a special case
for them, as you're not going to print the properties of the
placeholders (nor the packing properties, as you say later ;)

> This way the tree
> data structure implemented by GladeWidget->parent and
> GladeWidet->children would be a complete memory representation of our
> xml structure (at each node in the xml - be it a widget or a 
> placeholder
> - would be represented by a GladeWidget: eg a vbox with 3 
> slots in which the second one contains a button would be a 
> GladeWidget with 3 children GladeWidgets, one where 
> GladeWidget->widget is a button and the other two where 
> ->widget is a placeholder)
>
> Not that it matters much. While I was talking you did the 
> code so you are right by definition :)

Oh no!  I will not try to impose my opinion just because I happened to
have working code before :)
I hope that others will agree that the way I did it it's the right one.
Having it working with a ~5 lines change is anyway a nice side effect
;-)

> > What I was thinking is instead to just change the logic of 
> > glade_widget_write. Right now, it looks on the list of childrens of 
> > the GladeWidget. Instead, look at the list of children of the 
> > GtkWidget with gtk_container_get_children (only if it's a 
> container), 
> > and then for each children, we have 3 possibilities:
> >
> > 1) it's a widget with an associated GladeWidget
> > 2) it's a placeholder
> > 3) neither of these
> >
> > In case 1, we just keep with the current logic (redoing 
> > glade_widget_write, etc.), in case 2, we print the 
> <placeholder/>, and 
> > in case 3, we just ignore the widget.
>
> I should look at your changes before writing this (I'll do 
> asap), but does the above mean that we can get rid of our 
> tree structure completely? If that's the case we've somewhat 

Maybe, I don't remember if the list of children on the GladeWidget is
useful in others part of the code, but if it serves no purpose other
than duplicating the info that we already have with gtk, without giving
us any benefice (like better performance or something) then I'm all for
removing it.

> reversed the design of how things
> works: we used to have our tree of gladeWidgets which was the 
> main data structure and each gladeWidget had a gtkWidget 
> associated to it; now our main structure its determined by 
> how each gtkWidget it's contained by another and for each 
> gtkWidget we retrieve the associated GladeWidget to get some 
> info. I'm not saying that it's better or worst I'm just 
> trying to understand wehere we're heading.

I'm heading to the latest explanation.  I don't know until which point
the initial design wanted to be like your first explanation, but the
latest one is what makes the most sense to me.

> Do we really need packing properties for a placeholder? 
> AFAICS glade-2 just put
>
> <child>
>   <placeholder/>
> </child>
>
> which after all makes sense, since the packing properties of 
> a placeholder are always the default ones since you can't 
> edit them. Or am I missing something?

No, it's just me :)
I though that we need them, but it doesn't makes sense... I should stop
coding after midnight

Thank you for your comments!

Cheers,

P.S.: Archit seems to experience hangs when saving after this patch, but
it's working here (on windows).  Do you have a backtrace?