Re: 'reloading' gtktreeview when model changes drastically

[Philip Van Hoof <spam pvanhoof be>]

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