GNOME.org
 

Re: [gtkmm] Custom TreeStore Problems

I am writing a program that has a rather complex tree representation. I need a Gtk::TreeModel that will keep up-to-date with the internal data structures. The way that I want the user to see the information is slightly different from how they are actually stored in the internal data structures. Thus, it has become rather hard to keep the data in the Gtk::TreeStore up-to-date with the actual internal data. By writing a custom Gtk::TreeModel that wraps around the internal data rather than trying to mimic it, the custom TreeModel can never become out of sync with the internal data--something that has been driving me nuts off-and-on over the past few weeks.
The software that I am writing is an animation package. So if I want to show parameters being animated, I have to keep all of the values in the Gtk::TreeStore in sync by updating the entire table. If I am working on a large composition, this process is slow and inefficient--especially since I can only view a handful on the screen at a time. By writing a custom Gtk::TreeModel, there will be no need to have to parse through the internal data structures to copy data redundantly--the Gtk::TreeView will ask the custom Gtk::TreeModel what it needs when it needs it, and it won't ask for anything else.
In this case, implementing a custom Gtk::TreeModel, will have make the program more robust, more responsive, and more efficient. 

--- darco
http://www.deepdarc.com/
On Tuesday, April 29, 2003, at 01:15 AM, Murray Cumming Comneon com wrote: 


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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]