Re: 'reloading' gtktreeview when model changes drastically

["Milosz Derezynski" <internalerror gmail com>]

As a somewhat related topic (this thread seems to not be nailed on a
very specific topic yet and this still fits in i think), a
changeset+commit API (in the truer sense; not what was proposed with
just saying "all nodes below this one have changed") would be _very_
welcome for gtkmm, because right now, setting row data looks like this
(snippet from our code):

--snip--
    void
    Playlist_V::put_track_at_iter (Track const& track, Gtk::TreeModel::iterator & iter)
    {
      (*iter)[m_track_cr.track] = track;
      (*iter)[m_track_cr.uid] = track.bmpx_track_id

;
      (*iter)[m_track_cr.localUid] = m_localUid;
      (*iter)[m_track_cr.searchKey] = track.title ? track.title.get() : std::string();
      (*iter)[m_track_cr.playTrack] = track.active.get();
--snip--

And
yes, this is exactly how it looks like: The row is accessed for each of
those lines, and each uses a separate call to list_store_set()
internally. Yes, it i disastrous to performance. One guy on the
gtkmm-devel list recently made a benchmark and found that the gtkmm way
of doing this is approximately 75 times (not 75% -- 75 times) slower
than the C Gtk+ method.

Now without going to deep into C++, let's just say that with
the way gtkmm at least works, if not to be sane C++ altogether, it's
not possible to have a C-like TreeModel API in gtkmm, and that's where
the changesets come in.

I've been already thinking of a transactional system for
TreeModel, and i have some ideas, but nothing that could be put to code
right now.

_However_, a native API for this in C TreeModel
(perhaps an additional interface to TreeModel?
"GtkTreeModelTransactional"?) would make this task very simple because
then it could be normally wrapped without needing gtkmm-specific API.

Kris if you are really on to having a TreeModelTransactional
Iface, please just say "yeah", and i'll also start working on something
(deadchip in #gtk+, btw). This would be a major help for the other
discussed problems here, as well as for this one.

-- Milosz

On 6/24/07, Kristian Rietveld <kris gtk org> wrote:

On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> This seems to break the MVC abstraction - if the model changes
> drastically, I need to know which tree-views are connected so I can
> disconnect them? Bad!
>
> We need some new API I guess - which signals any connected views that
> the data it has cached about the model should be invalidated, and that
> the model may be changing without emitting signals.
>
> Once the model is updated, a further signal will inform the view that it
> can keep cached state again.

In practise this won't be all that different compared to setting a new
model on the tree view, except that with a signal it will be initiated
from the model.  After the model emits the "I am finished changing
everything" signal, the tree view will have to rebuild its internal
rbtree by iterating over the full model again (any other model that is
connected to this model will have to rebuild its internal state tree
too), since it has no clue what has changed.  This will probably also
involve unreferencing all nodes when the model emits "invalidate" and
re-reference the new nodes after the mass changing, and remembering
selection and expansion state during the mass-changing (this information
is kept in the internal rbtree too), etc.

I think a much better solution would be to be able to group a bunch of
changes together in a kind of "atomic changeset" which is then emitted
with a single signal.  All connected views/models could then process the
full changeset in one pass.  (Possibly this could also add/remove ranges
of nodes, etc).


regards,

-kris.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list