                               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.

* DefaultTreeNode.child_row_objects needs to be improved.

* _DefaultTreeNodeChildren has unimplemented methods.

* 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.

* Implement advanced attributes (started in 0.1.3).

  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.

* Find a way to parameter 'new_order' of 'rows-reordered' signal.
  Without testing that is too easy to make errors.



                                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.

* 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.

* An idea I had after a short IRC discussions: auto-columns.
  Basically, hide column numbers from users completely, or retain them
  for backward compatibility, but make optional.  The goal is to make
  things work this way:

      store = RowObjectListStore ()  # *No* columns!
      ...
      column = gtk.TreeViewColumn (None, gtk.CellRendererText (),
                                   text = store ('foo'))

  Maybe it should be "store.auto ('foo')" or something instead.
  Anyway, if combined with advanced attributes idea (see above), this
  can reinforce model/view separation.  For instance, instead of
  having columns for "number x" (for sorting) and "number x formatted"
  (with two digits after point), you could instead just get
  auto-column 'fmt:#.##:x' (or whatever syntax there would be).

  Columns would still be there, but they would essentially be hidden
  from users.

  This would also indirectly solve previous item (modifiable
  structure).

* Cache cell values.  This would be especially useful for cells in
  columns that correspond to non-trivial properties.  And especially
  when advanced attributes are implemented.  Obviously, caches for a
  row need to be refreshed when the row changes.

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