[glade--]Re: GtkCombo Help

[Christof Petig <christof petig-baender de>]

Bryan W. Headley wrote:
> We have a Combo in our glade-2 project,
>
> <widget class="GtkCombo" id="combo1">
>     ...
>    <child internal-child="entry">
>     <widget class="GtkEntry" id="combo-entry1">
>         ...
>     </widget>
>   </child>
>
>   <child internal-child="list">
>     <widget class="GtkList" id="combo-list1">
>          ...
>     </widget>
>    </child>
> </widget>
>
> This generates,
>
>     Gtk::Entry *combo_entry1 = manage(new class Gtk::Entry());
>     Gtk::List *combo_list1 = manage(new class Gtk::List());
>     Gtk::Combo *combo1 = manage(new class Gtk::Combo());
>
> 1. Gtk::Entry *combo_entry1 is really combo->get_entry();
>
>     That code you have in combo.cc only works for glade-1.

Correct, I shouldn't expect glade-2 to leave anything as it was before 
... The key is the WriterBase::IsSubwidget function. The matter is 
really complex but adapting the glade-1 handling to the glade-2 xml 
layout should be straightforward.

A related function is Widget::ChildName() which seems not to work.

> 2. Gtk::List is a deprecated widget. Not in gtkmm. But if it were, it'd
> be combo->get_list(). But I think gtkmm took that accessor out

We should not need that widget. (see above)

> 3. So. How do I ask a widget whether it is a child? Who it's parent is?
> Actually, it might be more useful to get the <child internal-child="xx">

That's what ChildName is for. What makes this complex is the fact that 
internal widgets might even nest (dialog: an internal hbox in an 
internal vbox which also carries non internal widgets.) So it's not easy 
to tell which parent to test. But that was solved long ago within 
const_contained_iterator (internal_determining_widget).

> 4. The temptation is to ignore these children widgets. But, for the
> combo, the Entry widget has properties that you, I know, want very much
> to see.
>
> I'm not sure how to proceed. How do you want to deal with this?
>
> And, if it later becomes too painful, are you prepared to drop support
> for glade-1? Otherwise, there may be a LOT of dynamic behavior in these
> writers when we're done. Dynamic header file names is very minor
> compared to what I'm thinking about.

Since it's solved for 1, glade-2 should be easy to implement. I think 
the ChildName is different, that's all.

PS: Trying to solve every widget possible is perhaps too much at once.

   Christof