                               GENERAL

Some things that are endless and cannot be decisively completed.

* Add more unit tests.

* Improve documentation.

* Add more examples, especially something useful.  It is difficult to
  strike right balance between simplicity and usefulness though.



                      UNFINISHED IMPLEMENTATIONS

Unimplemted branches in existing methods etc.

* TreeViewUtils.get_viewport_rows() doesn't work with non-list models.



                       THINGS THAT MUST BE DONE

These certainly must be done sooner or later.  Better sooner, but
definitely before the first stable version.

* Add an implementation of tree store.

* Implement advanced attributes.  First of all, it should be possible
  to specify attributes like 'foo.bar' and that should take property
  'bar' of property 'foo' of row objects.

  More advanced idea: have attributes (optionally) have the form
  'PREFIX:...', i.e. some string with a colon following it and then
  some text.  Operation prefix would define how the following text is
  processed and, ultimately, how attribute is retrieved.  For
  instance, 'none-safe:foo.bar' could be like 'foo.bar' except that if
  value of 'foo' is None accessor wouldn't try to get 'bar' on it.

  Even more advanced idea: allow to register custom operation
  prefixes.

* Add some utility methods to easily get selection from a model
  sitting behind a gtk.TreeModelSort.  I.e. spare users of this
  library from that 'convert_iter_to_child_iter' nightmare.  If
  possible don't restrict to selection, make it as general as you can
  without losing usefulness.



                                IDEAS

These are some random ideas.  May or may not be implemented.

* Think if it is worth it to have another implementation of list store
  based on linked list.  Advantage would be persistent gtk.TreeIter.
  On the other hand, we try to reduce need to use those anyway.  Also,
  having another implementation without big differences is somewhat
  confusing and might become a maintenance problem.

* See if implementing gtk.Buildable is worthy.  In general, see if it
  is possible to integrate with gtk.Builder and Glade.

* See if it is possible to fix PyGTK to allow implementing
  gtk.TreeSortable.

* Think about modifiable model structure, i.e. number and attributes
  of columns.  When implementing think if we should be bitchy and not
  allow removing existing columns (might be used, bla-bla-bla) or
  permissive?  This needs one or two real-world use cases to create a
  good interface from the start.

* Once things stabilize, see if reimplementing some crucial stuff in C
  helps performance.
