Re: [gtkmm] TreeView Design

["Daniel Evison" <devison pacificit co nz>]

 > On Thu, 2002-07-18 at 09:55, Daniel Evison wrote:
 > > Well, the book chapter doesn't have that extra level of complication,
but it
 > > doesn't address how to make a TreeView connect with underlying
(non-gui)
 > > models in an application.
 >
 > A model is meant to be non-gui. Maybe you mean non-gtkmm.

I guess so.  However, the ListStore class is in a library that also has a
lot of gui stuff, and requires linking in various other gui libraries.  I
must admit I don't know too much about the ListStore class but don't think I
would otherwise be wanting to use it in its own right - it isn't as
sophisticated a container as say a templatized STL container.
If I was making a command-line only version of an application it would seem
like a pity to be forced into having to use the gtkmm libraries just because
one type of view you wanted (in another program) was gtkmm, and all your
containers were ListStores.  Or if I was releasing a library of say
financial application logic which people could use to build applications it
would seem a pity to have a dependency on gtk.  (I would expect to release
another library that provided views of the components in gtkmm for people
that wanted it).

It is possible to separate the dependency.  It seems the main issue comes
down to the fact that the TreeView class requires the data to be in a
certain type of model, and that the information must be copied by value into
that model.  I think it would be better if it could interface with data in
various formats (including standard C++ containers), through functors,
functions, etc.   It seems to me like a simpler approach too (though I don't
understand the inner workings of gtk and its assumptions and constraints).

 > > I believe
 > > you would still have to duplicate the data.
 >
 > Most of the time I think it's OK to use the ListStore or TreeStore. The
 > standard models don't seem to have much support for stuff like backend
 > database connections. ETable does that apparently.

There are also efficiency considerations.  If your application data is in
ListStore then the interface to it is through quite a complicated proxy.  If
your data was being used in say compute-bound simulations then this is
significant compared with having normal C++ classes like Employee and
vector<Employee>.

 > >  And so if a field is edited
 > > then the callback would have to update both the ListStore and the
underlying
 > > model.   Normally I think an application should be written with
data-types
 > > that don't know anything much about the gui widgets that will be used
to
 > > display them, since it may have multiple different kinds of interfaces
 > > layered on it.
 >
 > It's an interesting question, but one that would be answered more
 > completely on gtk-list or gtk-devel-list.
 >
 > > Would you extract out all the fields from the Employees and copy them
into a
 > > ListStore, or is that not necessary?
 >
 > Firstly, I'd avoid that and just use ListStore or TreeStore.
 >
 > If I really had to, then I'd do one of these:
 > 1. Keep them in sync, like you say.
 > 2. Derive a new TreeModel. Very difficult. No examples exists.
 > 3. Investigate TreeView::insert_column_with_data_func() to
 >    see what it is and whether it's useful.

I'm going to at least look into 2 and 3, since I don't like the idea of
using ListStore and TreeStore pervasively through my application logic, and
1. seems complicated and potentially error prone.

I'm interested in your comments.
thanks,
Dan