Re: RFC: new features

[Christian Hergert <chris dronelabs com>]

On Fri, 2012-01-13 at 17:21 -0500, Paul Davis wrote:
> 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.

Additionally, if we were to go down this path, having the ability to
have "sections" would be lovely. The way this seems to get done now is
with "dummy rows" that get styled differently by the cell renderers and
extra work to avoid selections. This means that you have little to no
consistency between applications. Also, it should be styled by the css
themes.

Essentially, something like the sections in the Nautilus sidebar.
However, it would need to scale slightly better since one might use it
to group emails by day, week, month, etc.

-- Christian