On Wed, 2007-12-12 at 11:33 +0300, Andrew E. Makeev wrote: > В Втр, 11/12/2007 в 12:53 -0600, Joaquim Schmidlap пишет: > > We are going to be creating many TreeView/ListStore based applications here > > that have to work with our in-house asynchronous message architecture. I've > > successfully prototyped this kind of application by using a message queue. > > Instead of writing directly to the model, I put the data on the message > > queue, > > and use a Glib::Dispatcher to notify the Gtk thread to pull the data off the > > queue and put it into the model. Works great, but requires several steps. > > > > What I'd like to do is wrap those steps up so my users can still write to > > the model via the Row::operator[] or Row::set_value() interfaces, and all > > the queueing stuff would happen behind the scenes for them. I'd like to > > leave the rest of the ListStore (and supporting class) interfaces alone as > > much as possible. > > > > Can anyone offer a roadmap or an example on how to proceed from here? At > > first cut, it looks like deriving from ListStore is a lot of work, and might > > require me to build my own iterator classes, etc. which seems like a lot of > > work. Or, is there a better way to wrap up the behavior I want to hide? > > > > Actually, there is not so much work to implement your own TreeModel. > > Look at treemodelcustom/ example, and read documentation carefully > (there are few method implementations missed in example to make it work > completelly right). > > And you should derive from TreeModel, TreeModelSortable (if you will > implement sorting). > > Unfortunatelly, you have to implement Iterator behavior, but that's not > so complicated as you may think. You shall learn everything from > example.
I still don't think that deriving a TreeModel is documented well enough, but yes, it's possible. Depending on the situation, you might also solve your problem by using the cell_data_func() technique: http://www.gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1TreeViewColumn.html#765296845c9e9757ba405becbbc13d96 That would allow you to store some reference/ID in the model, but get the actual row values only when they are needed, maybe even using some signal_idle() technique to get them asynchronously. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
