RE: [gtkmm] Custom TreeStore Problems

[Murray Cumming Comneon com]

I think it would be very useful to know when it's useful to implement a
custom TreeModel.

Murray Cumming
murrayc usa net
www.murrayc.com 

> -----Original Message-----
> From: darco [mailto:darco deepdarc com] 
> Sent: Dienstag, 29. April 2003 10:13
> To: Thomas Muldowney
> Cc: GTKMM Mailing List
> Subject: Re: [gtkmm] Custom TreeStore Problems
> 
> 
> Woo-hoo! After examining your code, I found out what I was missing -- 
> apparently I was doing the whole Glib::Object initialization wrong. 
> Thanks a bunch, your example helped a lot!
> 
> I corrected my customtrreestore.tar.gz example, and it is now 
> online if 
> anyone wants to look at it.
> 
> On Monday, April 28, 2003, at 08:45  PM, Thomas Muldowney wrote:
> >
> > I'd be more than happy to answer questions about what I 
> did, or receive
> > any feedback about more correct ways to do things.  
> Especially related
> > to the RosterModel_Class (Glib::Class).
> >
> 
> I noticed in your code that you set the iterator stamp to a constant 
> value (42). While I'm not quite sure how the stamp of the iterator is 
> suppose to be handled, I handled it by having a different stamp value 
> per model instance. The stamp value is stored in the model, and is 
> calculated at construction. Perhaps one could also recalculate that 
> stamp when iterators become invalid...? In my example I check the 
> validity of iterators in all of the virtual functions, 
> although I'm not 
> sure if that's what I am suppose to do. (I calculated the 
> stamp to be a 
> unix timestamp + the address of the TreeModel instance.)
> 
> Then again, that topic is probably more suitable for a different 
> mailing list.
> 
> --- darco
> http://www.deepdarc.com/
> 
> PS: Here is the full message that Thomas sent me, as it seems 
> as though 
> it didn't quite make it to the mailing list:
> 
> On Monday, April 28, 2003, at 08:45  PM, Thomas Muldowney wrote:
> 
> > I've recently battled through this myself and have defeated 
> it!  That's
> > to say I got something working.  I'm not sure if it's 100% 
> correct, but
> > it seems to be working great.  The code is available in the Gabber2 
> > CVS,
> > you can use viewcvs.cgi here:
> >
> > http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/gabber/src/
> >
> > RosterModel.cc and .hh have the actual model 
> implementation, and it's
> > used as the model for the treeview contained in RosterView.
> >
> > I'd be more than happy to answer questions about what I 
> did, or receive
> > any feedback about more correct ways to do things.  
> Especially related
> > to the RosterModel_Class (Glib::Class).  I'd also be 
> willing to write 
> > up
> > a small tutorial with more simple code and implementation 
> if the code
> > I've written is deemed mostly correct =)
> >
> > --temas
> >
> >
> > On Mon, 2003-04-28 at 20:45, darco wrote:
> >> I am trying to implement a Custom TreeStore using GtkMM. Unable to
> >> find any documentation on how to do this, I figured I 
> would just give
> >> it a shot and see if I could figure it out. But I have now 
> come to a
> >> point where I am stumped. I'm not sure if I'm just missing 
> something,
> >> or if it is a bug.
> >>
> >>
> >> Seeing as there is no example for creating a custom tree 
> store in the
> >> GtkMM tarball, I wrote a small program that (if it worked) would
> >> demonstrate how to do this. After if is fixed and working, 
> it might be
> >> helpful if it were included into the tarball (or perhaps elsewhere)
> >> for others to examine.
> >>
> >>
> >> Right now, I'm getting the following runtime errors:
> >>
> >>
> >> <fixed><fontfamily><param>Courier 
> >> New</param><bigger>(customtreestore:343):
> >> glibmm-CRITICAL **: file interface.cc: line 53
> >> (Glib::Interface::Interface(const 
> Glib::Interface_Class&)): assertion
> >> `gobject_ != 0' failed
> >>
> >>
> >> (customtreestore:343): glibmm-CRITICAL **: file 
> interface.cc: line 53
> >> (Glib::Interface::Interface(const 
> Glib::Interface_Class&)): assertion
> >> `gobject_ != 0' failed
> >>
> >>
> >> (customtreestore:343): glibmm-CRITICAL **: file 
> interface.cc: line 53
> >> (Glib::Interface::Interface(const 
> Glib::Interface_Class&)): assertion
> >> `gobject_ != 0' failed
> >>
> >>
> >> (customtreestore:343): glibmm-CRITICAL **: file 
> interface.cc: line 53
> >> (Glib::Interface::Interface(const 
> Glib::Interface_Class&)): assertion
> >> `gobject_ != 0' failed
> >>
> >>
> >> (customtreestore:343): GLib-GObject-CRITICAL **: file 
> gobject.c: line
> >> 1319 (g_object_ref): assertion `G_IS_OBJECT (object)' failed
> >>
> >>
> >> (customtreestore:343): GLib-GObject-CRITICAL **: file 
> gobject.c: line
> >> 1337 (g_object_unref): assertion `G_IS_OBJECT (object)' failed
> >>
> >>
> >> (customtreestore:343): GLib-GObject-CRITICAL **: file 
> gobject.c: line
> >> 1337 (g_object_unref): assertion `G_IS_OBJECT (object)' failed
> >>
> >> </bigger></fontfamily></fixed>
> >>
> >> Oddly enough, several of these errors appear when I am copying the
> >> Glib::RefPtr<<> for the CustomTreeStore! I find this to be most
> >> bizzare. NONE of the virtual functions are being called, 
> and I don't
> >> know why. Is it possible that I'm not using the Glib::RefPtr<<>
> >> correctly?
> >>
> >>
> >> I saw that someone earlier mentioned having similar problems and
> >> Murray suggested the following:
> >>
> >> <excerpt>I suspect that a custom Store might require similar
> >> techniques as a custom CellRenderer, because it might require the
> >> definition of a new GObject type at runtime. You should 
> probably look
> >> at the constructors in the custom cellrenderer example.
> >>
> >> </excerpt>
> >>
> >> I just wanted to say that I am doing this, and the program still
> >> yields the results shown above.
> >>
> >>
> >> The source code to this example can be found here:
> >>
> >> ftp://ftp.voria.net/pub/customtreestore.tar.gz (Or if you 
> prefer http,
> >> use http://ftp.voria.net/pub/customtreestore.tar.gz )
> >>
> >>
> >> Thanks in advance!
> >>
> >>
> >> --- darco
> >>
> >> http://www.deepdarc.com/
> >
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>