Re: RFC: new features

[Paul Davis <paul linuxaudiosystems com>]

On Fri, Jan 13, 2012 at 4:51 PM, Alberto Ruiz <aruiz gnome org> wrote:
> I think that if we were up to do this, we should go ahead and get rid of
> GtkTreeModel altogether and substitute it for something like libmodel.
>
> The data driven app situation in GObject/Gtk+ is quite sad at the moment and
> there's a lot of code that could be reused (like data/search filtering and
> data model backends) if we had a proper collection/data model API in place
> and used by the toolkit.

there is a bigger issue there, i think. in an ideal world, you don't
want to base the date store for the TreeView on an object, but on an
interface.  then you want a series of adapters/wrappers that wrap data
structures implemented in any language (or any language with a GTK
binding) with the required interface. some of which might be "null"
adapters that just do passthrough to the underlying data object.

there's nothing more stupid that taking a "native" data structure
(e.g. a C++ list, a python array, some app-specific creation, etc) and
having to copy the data out of it into some GObject-based data
structure before being able to give it to the TreeView. well, ok,
there are lot of things that are a lot more stupid than that, but its
still pretty aggravating. yes, i understand that GTK sits atop GObject
in some fairly fundamental ways, but the TreeView is about displaying
application data, not GTK state, and a much simpler mechanism for
allowing the use of the data structures already in place in an app
would be super-welcome.