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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
