Re: [gtkmm] Feature Wish: ad-hoc or external properties for simplified data binding

[Matthew Walton <matthew alledora co uk>]

Andreas Pokorny wrote:

> On Tue, Aug 03, 2004 at 02:48:47PM +0100, Matthew Walton <matthew alledora co uk> wrote:
> > What you appear to be wanting here is a seperation of data and 
> > presentation (or Model-View-Controller), which is a fairly classic 
> > concept from all sorts of places. You should find that the TreeView 
>
>
> Yes, thats what I want, but I would hate an interface in which I had to
> derive from some base model class just to wrap the model of a text field.
> Then again you would have to write a lot of interface code to "get your
> data into the gui". 
>   I propose a system that works without strong coupling of Gui classes 
> and user classes, and more important than that, a system  which saves a 
> lot of lines of code. 

Gtk::TreeModel is really just an interface - it's there to ensure that 
all models have the required methods available for Gtk::TreeView to call 
to get what it expects. That's not a particularly onerous thing.

Are you thinking of something where instead of providing a model object 
to the TreeView, you instead get the TreeView to call your own supplied 
functions or methods to obtain its data? If so, that's really just a 
different way to the same end (probably a messier one in my opinion). If 
you're thinking of something else, I'd be interested to hear you explain it.

> > widget (and the ComboBox in gtkmm 2.4) already have this abstraction - 
> > to use any external data store, you just have to wrap it in an interface 
> > derived from Gtk::TreeModel. TextView also has an external data store, 
> > so you could write a wrapper for more or less any source of text you 
> > cared to use for that. Other widgets don't already have it (the new 
> > sheet widget for GTK 2.8 will be using MVC as I understand it), but they 
> > could probably be coerced into it with a bit of effort.
> >
> > That said, though, other widgets don't have substantial internal data 
> > storage - buttons have very little state information inside them, as 
> > also for checkboxes and so forth, which is why the widgets which do use 
> > MVC use it and the ones which don't, well, don't.
>
>
> Even that little data should be stored in the users object. But I think,
> that with the current design of gtkmm, this decision is done by the gtk+
> developers, isn't it?

Yes. gtkmm decides how to wrap GTK+ in C++, but the actual functionality 
and structure of the toolkit is down to the GTK+ developers.