[glade--]Re: glade-- patches

[Christof Petig <christof petig-baender de>]

Bryan W. Headley wrote:
> Ah, you want to do rewrites on the menu writers. Okay, I'll look into that.
It's already done. MenuItem now has three specific methods which are 
used by menu to create the menu->push_back(MenuElem). This would be the 
way I'd love to go with toolbars, too.
> You understand, especially last week, I was just trying to get something 
> that will work. I'm slowing down, because of the XML parser, and the 
> internal child widget names, etc. But some this DOES call for 
> design/redesign.
Did you understand the concept of Widget/const_contained_iterator. These 
classes abstract the whole XML layer in classes. So doing xml magic 
(like calling routines when tags are encountered) does not appeal to me 
[glade-- has too many cross references (e.g. when connecting signals to 
other widget's method)]
If I get your current problem right, you want to emit special code to 
set properties on toolbar buttons. And for this you need to know which 
toolbar contains your button. Is this right?
- does the menu like approach fit your needs? (you can add as many 
button specific toolbar related callbacks as you like, with almost any 
argument you like, even the toolbar)
- if this doesn't help: Can this be done via comparing ChildName() to a 
magic value?
- if not: seems we need to attach Widget s to the corresponding Tag s 
and provide a method to walk the tree up (to the parent). Does this 
appeal to you?
> This ought to be fun; murray and this guillaume guy are having a public 
> fight about gtkmm, kde, who-did-what in the past, who-betrayed-who in 
> the past, and Inti. And here, something similar to Inti arrives on 
> sourceforge in the same week. This could be fun. BTW, the guy says he 
> might write his own IDE.
I'd vote for ignoring people which compensate their inability to 
cooperate with just another sourceforge project. Which does not mean 
that new ways are always inferior.
    Christof