RE: [gtkmm] Obtaining a pointer to an object

> -----Original Message-----
> From: Christer Palm [mailto:palm nogui se] 
> Sent: Monday, July 12, 2004 3:24 PM
> To: Miller, Ryan D
> Cc: gtkmm-list gnome org
> Subject: Re: [gtkmm] Obtaining a pointer to an object
> Miller, Ryan D wrote:
> > 
> > That sounds like a simple solution I'll hack in for now.  Thanks 
> > Christer!  What I was hoping for was a way to not need to rely on 
> > having the parent class having accessors to each class pointer.  
> > Eventually, everything will be declared dynamically as needed, so I 
> > was hoping there might be something I could use in Gtk (like 
> > Gtk::manage) that kept track of the objects and their hierarchy.
> > 
> Well, gtkmm does of course keep track of the widget hiearchy 
> and you can 
> traverse it, although this is not very simple.

Nothing ever is. :)

> But normally, it would be 
> good design to avoid having objects magically modifying objects other 
> than "child" objects without someone telling them to. Perhaps if you 
> told us more about what you are looking to achieve on a higher, not 
> technical, level?
> --
> Christer Palm

On a higher level, I'm using glade and glademm to create prototype for a
dynamic build utility.  In my main window I have, among other things, I
have a folder browsing widget (based on a treeview) and a customized box
class to display certain files from certain selectable folders in the
browser.  I was hoping to connect the changed signal from the tree view
widget to a function in the box that would verify a path sent with the
signal (via sigc::bind) and display the path contents.  I'm hesitant to
tear into the parent window class because the browser widget and box
will be changing to different varieties (all tree view and box derived,
but not much else in common) depending on the step in the build process.
Also, because I'm using glade, my main class is derived from the
main_glade class - which "ideally" I don't want to edit, but it contains
all the class declarations and gtk::manage calls.

That's the high level view.  It is just a rapid prototype and I don't
want to waste people's time with a software design issue, which is why I
was hoping there might be a simple way to browse the widget hierarchy.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]