Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> > On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> >
> > > 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.
> >
> > I'm a big user of MVC. Although on some level I agree with you, I would
> > ask what the difference is between:
> >
> > void gtk_treeview_freeze (GtkTreeView* tv) {
> > /* store model in tv, then unset */
> > }
> > void gtk_treeview_thaw (GtkTreeView* tv) {
> > /* reset model in tv */
> > }
>
> Owk .. it's a bit lengthy and there are a lot of "personal opinions
> about MVC" embedded in this one:
it didn't need to be so lengthy :) thats why i noted that i use MVC a
*lot* myself. the key point you raise is one that i had forgotten: there
may be multiple views on the model, and when changing the model, one
should not be required to know about the number of views. excellent
point, end of story for me. it ought to be "transactional".
--p
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> 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.
I'm a big user of MVC. Although on some level I agree with you, I would
ask what the difference is between:
void gtk_treeview_freeze (GtkTreeView* tv) {
/* store model in tv, then unset */
}
void gtk_treeview_thaw (GtkTreeView* tv) {
/* reset model in tv */
}
and just calling gtk_treeview_set_model (NULL) and
gtk_treeview_set_model (NOTNULL).
there are additional issues: freeze/thaw semantics require use of a
counter, so that, for example, if 3 nested contexts call "freeze", only
the 3rd subsequent call to "thaw" actually unfreezes. contrast this to
the simplicity of code in which only the top level sets+unsets the
model, and all lower levels act on the model regardless of whether its
connected to a view or not.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 04:24 +0200, Milosz Derezynski wrote:
> Just FWIW, can we agree on one meaning of "transactional"?
> For me, the fact that the model shouldn't have to know about the
> number of views showing it has nothing to do with transactionality:
>
> > there may be multiple views on the model, and when changing the
> model, one
> > should not be required to know about the number of views. excellent
> > point, end of story for me. it ought to be "transactional".
>
> I think the most sensible meaning is the one we e.g. know from SQL and
> which Kris mentioned: One atomic changeset which can be "committed" to
> the model in one run. (It can probably not be rolled back, or if it
> would be possible, then it'd be quite expensive, but that's not really
> the point anyway).
For me, what is important is that MVC is that what it is supposed to be:
-> View observes Model
And not:
-> Some extra code done by the application developer observes for
the View the Model, because the View can't cope with the actual
MVC paradigm.
The simplicity of MVC is also what makes it so useful. By assuming that
the application developer will "solve" all the problems that the normal
"View observes Model" solves (he has to reset the model, he has to reset
the view's state, he has to detect changes to the model, ...) you void
the simplicity.
If the view internally actually resets its model, then that's fine.
It's a complexity that got solved by the View and didn't have to be
solved by the application developer. If it's more easy for Kris to
internally swap the Model (reloading everything and recovering the
state, like sorting --in case of a sortable -- or selection details),
then that's fine from the application developer's point of view.
> As for the model-should-be-view-ignorant issues, they have nothing to
> do with transactions, but are just as valid concerns of course.
>
>
> On 8/5/07, Paul Davis <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> > On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> > > On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> > >
> > > > 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.
> > >
> > > I'm a big user of MVC. Although on some level I agree with
> you, I would
> > > ask what the difference is between:
> > >
> > > void gtk_treeview_freeze (GtkTreeView* tv) {
> > > /* store model in tv, then unset */
> > > }
> > > void gtk_treeview_thaw (GtkTreeView* tv) {
> > > /* reset model in tv */
> > > }
> >
> > Owk .. it's a bit lengthy and there are a lot of "personal
> opinions
> > about MVC" embedded in this one:
>
> it didn't need to be so lengthy :) thats why i noted that i
> use MVC a
> *lot* myself. the key point you raise is one that i had
> forgotten: there
> may be multiple views on the model, and when changing the
> model, one
> should not be required to know about the number of views.
> excellent
> point, end of story for me. it ought to be "transactional".
>
> --p
>
>
>
> ___
> gtk-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
Just FWIW, can we agree on one meaning of "transactional"?
For me, the fact that the model shouldn't have to know about the number of
views showing it has nothing to do with transactionality:
> there may be multiple views on the model, and when changing the model, one
> should not be required to know about the number of views. excellent
> point, end of story for me. it ought to be "transactional".
I think the most sensible meaning is the one we e.g. know from SQL and which
Kris mentioned: One atomic changeset which can be "committed" to the model
in one run. (It can probably not be rolled back, or if it would be possible,
then it'd be quite expensive, but that's not really the point anyway).
As for the model-should-be-view-ignorant issues, they have nothing to do
with transactions, but are just as valid concerns of course.
--Milosz
On 8/5/07, Paul Davis <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> > On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> > > On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> > >
> > > > 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.
> > >
> > > I'm a big user of MVC. Although on some level I agree with you, I
> would
> > > ask what the difference is between:
> > >
> > > void gtk_treeview_freeze (GtkTreeView* tv) {
> > > /* store model in tv, then unset */
> > > }
> > > void gtk_treeview_thaw (GtkTreeView* tv) {
> > > /* reset model in tv */
> > > }
> >
> > Owk .. it's a bit lengthy and there are a lot of "personal opinions
> > about MVC" embedded in this one:
>
> it didn't need to be so lengthy :) thats why i noted that i use MVC a
> *lot* myself. the key point you raise is one that i had forgotten: there
> may be multiple views on the model, and when changing the model, one
> should not be required to know about the number of views. excellent
> point, end of story for me. it ought to be "transactional".
>
> --p
>
>
>
> ___
> gtk-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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 <[EMAIL PROTECTED]> 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
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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 <[EMAIL PROTECTED]> 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
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
>
> > 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.
>
> I'm a big user of MVC. Although on some level I agree with you, I would
> ask what the difference is between:
>
> void gtk_treeview_freeze (GtkTreeView* tv) {
> /* store model in tv, then unset */
> }
> void gtk_treeview_thaw (GtkTreeView* tv) {
> /* reset model in tv */
> }
Owk .. it's a bit lengthy and there are a lot of "personal opinions
about MVC" embedded in this one:
Well I'm in favour of having a strict separation between code that views
data (the view), and code that represents the data (the model).
If you require that "using the model" is to be adapted or adjusted to
certain limitations, you are requiring that the model's code becomes
specific for the view. Let me explain:
Let's take the example with a person and a view for a person:
Person p = new Person ();
PersonView v1 = new PersonView ();
v1.Model = p;
I have another PersonView open on (another) screen (whether it's another
computer or another process or another whatever is irrelevant for now):
PersonView v2 = new PersonView ();
v2.Model = p;
Imagine I'm working at the p's town administration and I change person
p's name. Let's say we did this in v1.
We'll assume a simple system where each person has one instance in this
global system or where each system gets notified by triggers on the
remote database (quite Utopical, I know. But it's irrelevant. You can
also imagine one computer, one application with two PersonView instances
being visible at the same time, showing the same model -- the same
person instance, as we got the instance from a factory and the instance
is, indeed, the exact same instance --).
In v1's instance (image on_name_textbox_changed indeed happens) :
public class PersonView
{
public Person Model;
private void on_name_textbox_changed (TextBox o, ...) {
this.Model.Name = o.Text;
}
}
Note that maybe some people want to do this with a separate Controller
type, in which case we're in the exact same situation.
Now if we'd require that you always now refresh v1 and v2's model before
either v1 OR v2 (not "AND", because v1 can indeed update itself in the
on_name_textbox_changed method, but since PersonView should rather
observer its Model, we usually don't do this --but it can, I know--) ...
... how will v2 get itself updated in time?
It can't, because the view requires getting updated by having it set its
model each time it needs an update.
Now this is a simple example. Whether model is a list of rows, a tree of
things, a bear, a person, a traffic light (which is a typical example),
a remote control for a television ...
Whether the model is a list of 800,000 E-mails. Whether its 300,000 song
titles, ...
Doesn't matter for the MVC theory. You can always have a v1 and a v2
showing the same model instance.
When v1 causes a change to its model, and v2 shares the same instance as
model with v1, v2 should update itself instantly. Because both v1 and v2
observe the model.
Now the "update" (which gets called by the notify of the observable
model) of PersonView can of course do this internally (resetting its
model, resetting its state, doing this or doing that). That's just an
implementation detail.
In case of GtkTreeView this would mean that GtkTreeView would have to
implement this implementation detail. Not the application developer.
In GtkTreeView's case, if the changes are big .. its right now only
practical (else the performance is very weak, yadi yada) if you unset
the model and reset the model. But that's broken as illustrated in the
example above.
> and just calling gtk_treeview_set_model (NULL) and
> gtk_treeview_set_model (NOTNULL).
>
> there are additional issues: freeze/thaw semantics require use of a
> counter, so that, for example, if 3 nested contexts call "freeze", only
> the 3rd subsequent call to "thaw" actually unfreezes. contrast this to
> the simplicity of code in which only the top level sets+unsets the
> model, and all lower levels act on the model regardless of whether its
> connected to a view or not.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-06-24 at 15:19 +0200, Kristian Rietveld 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. That was the intention - its the same as the workaround described before, but is model initiated (avoiding the need to break the MVC abstraction). > 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. If the model changes underneath - its very difficult to say which nodes should still be selected / expanded (unless of course we use a change-set type arrangement as you suggest below. > 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). This sounds good, although its not entirely clear what such a changeset would look like. Such a change-set would have to be easy to produce, and flexible enough in its description that we can be vague.. (perhaps saying "everything below this node changed"?) Does anyone use these models for really huge data-sets? If so, I don't think the change-set (if it lists ALL changes in FULL) is as favourable as invalidating the model (or parts of it). Perhaps this is just not the intended use of the models though. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
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
Re: 'reloading' gtktreeview when model changes drastically
CC'd the -devel list as I think this is relevant there.. On Tue, 2007-06-19 at 11:56 +1000, Daniel Kasak wrote: > On Thu, 2007-06-14 at 21:54 +0200, [EMAIL PROTECTED] wrote: [snip] > > The data model often changes drastically, a lot of rows and > > subtrees are modified, deleted, created, etc. > If you change the model significantly, you want to do one of 2 things. > > Option 1 ) Create a new model, populate it, and then use > gtk_tree_view_set_model to tell the treeview about the new model, and > dump the old one. > > Option 2 ) use gtk_tree_view_set_model to point the treeview at another > ( empty ) model ( or maybe NO model ... I'm not sure if you can do this, > I've never tried it ). Then do your changes to the real model. Then use > gtk_tree_view_set_model once more to point the treeview back at the real > model. > > The idea with both of these approaches is that when you do lots of > changes to the model, it forces the treeview to keep updating, and this > is slow. It's best to do all your changes with the treeview > *disconnected* from the model, and then connect it back. Works for me > anyway. 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. Here is a possible interaction flow... Model: Emits "invalidate" signal View: Knows its internal state may loose track with the model, if it needs to ask the model for any information, it must not assume the model's state. Model: Re-populates without emitting any "changed" type signals View: (What does it do whilst we're repopulating??) Model: Still repopulating without emitting any "changed" type signals Model: Emits a some signal to notify that it has finished - any further updates emit "changed" type signals. View: Redraws? Anyway - the design might suck - IANACS (CS= Computer Scientist). Adding support of the new signal to the GtkTreeView ought not to break existing API, as old models just won't emit that signal. (IANAGTKDeveloper, so could be wrong about that). Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
