Re: 'reloading' gtktreeview when model changes drastically

[Philip Van Hoof <spam pvanhoof be>]

On Sun, 2007-06-24 at 15:19 +0200, Kristian Rietveld wrote:

> 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.

I agree with this and am in need of this kind of things too.

I'll give some real world examples of how GtkTreeView and GtkTreeModel
are being used today already:

In Tinymail while headers are being downloaded I need to "prepend" those
to a GtkTreeModel (during download, not while all are downloaded as that
is not what people nowadays want from an E-mail client: they want to
start using things 'as they get received').

Same for notify events (Push E-mail if you prefer the buzzword name):
these are events that "happen" and "can happen in any thread or
anywhere"). Such an even, for example in case the user used another
E-mail client to move 80,000 E-mails, will cause 80,000 row insertions
to happen.

Although this number sounds "large", in fact .. it's small. Some people
have over 300,000 items in their E-mail folders (talk to one of those
Ubuntu bugzilla maintainers, who made a IMAP folder for each Ubuntu
product on his IMAP server: he has thousands of folders and some folders
have ten or hundred thousands of items in it. And this ain't "rare",
really). Note that this is the guy being responsible for Ubuntu Mobile,
and would like to use this as test on his Mobile device (imo this should
be perfectly possible on a device that has 50MB of RAM).

Or look at Rhythmbox or Banshee: some people have over half a million
songs. A customer once asked me to make an analysis to port a software
jukebox on Windows to GNOME. With the software it was a possible
use-case or "event to support" to "suddenly" receive 300,000 new songs
and have 700,000 old songs removed. The people in the bar, the
listeners, don't want the software to stop playing. The guy at the bar
does not want the software to change the sorting order or settings when
this remotely invoked event happens.

I know I'm using a lot of words. I'm just really trying to make it clear
that unsetting the model and setting a new model is not a practical
method and that it's wrong from a Model View Controller perspective:

The model itself is the source. The view is just a viewer for it. The
source itself doesn't change. The content of the source changes. The
view, being an observer of the model in the MVC paradigm, should adapt
to the changes. It should not require a sudden set and unset of its
model.


Finally, Kris, if you need any assistance with this: you know where to
find me and you know that I'm interested in helping with this if
necessary.


>   All connected views/models could then process the
> full changeset in one pass.  (Possibly this could also add/remove ranges
> of nodes, etc).


Thanks for your hard work on GtkTreeView and Model! Make it rock!



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog