RE: [gtkmm] Custom TreeStore Problems

[Thomas Muldowney <temas box5 net>]

The problem we encountered with Gabber2 and the TreeModel is that most
of our model updates were coming from an external source.  In our case
it was the presence updates from our Jabber library.  The original way
we attempted to work around this was using the row reference system. 
This would be alright, but it is still not supported on Win32 builds,
which we are targetting with Gabber2.  While we could have waited for
that to be updated it felt odd to be creating a hacked model around our
already consistent data.  What clenched the decision was our addition of
different sorting methods and the ability to hide different segments of
the model.  Basically we ended up with something that migth be a list
store or might be a tree store.  We could have hacked this into the row
reference/TreeStore system, but it felt like the model was just growing
too much in odd directions.  It seemed like the most correct way (from
an object orientted standpoint) to tackle this was to create a new
model.  Really, the major factor was that most of our updates came
internally, not from user interaction with the view.  TreeStore didn't
really seem designed for the external update scenario.  Rather, it seems
more suitable for static data that can easily be traversed in a way
TreeStore wants you to.

--temas


On Tue, 2003-04-29 at 03:15, 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