GtkTreeView status report

[Jonathan Blandford <jrb redhat com>]

Hi,

I've written up a quick summary of a number of planned future features
for the GtkTree* family of objects.  The point of this is primarily to
let people know what's being worked on, and to solicit feedback on this
work.  I'm particularly interested in knowing people's thoughts on which
of these should be targeted at GTK+ 2.4, which don't belong in GTK+ at
all.  Comments on the actual features would be wonderful, as well as any
needed features that aren't listed.

I haven't included most of the GtkTreeView bugs, nor have I included
vague goals, such as 'performance' and 'stability', as important as they
are.  Additionally, I included some time estimates on how long I thought
it would take to integrate a feature with GTK+.  As with all estimates
of this nature, they should be taken with a large number of grains of
salt.

As always, volunteers to work on these would be appreciated.

Thanks,
-Jonathan

Item:     GtkCellRendererKeys
Status:   Written
Location: libegg
Usage:    gnome-keybinding-properties, gnome-terminal

  This class is a cell renderer that can be used for applications that
  set keybindings.  It is a pretty esoteric class, and is currently only
  used by gnome-keybinding-properties and gnome-terminal.  It's
  inclusion into GTK+ is a little suspect, as I don't see a lot of
  people using it.

  However, we've talked about having a generic accelerator editing code
  in any future GnomeApp like widget we may put in the library.  If
  that's a feature we want, then we will need a class like this.
  Additionally, changing keybindings isn't that outlandish, and it's
  possible that the reason that more applications haven't done so thus
  far is because it is so hard.  As it stands, the code seems to work
  pretty well for both users, and could be dropped into GTK at any time.

  Another issue is that it currently requires minor additions to gdk, so
  it's inclusion is dependent on those being approved.  These additions
  can be found in libegg/treeviewutils/eggaccelerator.[ch]

  Estimated time to get into GTK+: 1 day



Item:     GtkTreeModelFilter
Status:   Written
Location: libegg
Usage:    Rhythmbox

  This model wraps a child model, and potentially does three things with
  it.  You can provide a filter function to modify values from a child
  (and also change column types).  You can add a function or set a child
  column destination that allows you to toggle the 'visibility' of a
  row.  Finally, you can change the root node of the child model to be a
  different row.

  It is currently seems to work fine in Rhythmbox, and I'm reasonably
  happy with the API.  It may need a small cleanup, and will want some
  testing and review.  It is very similar in design to the sort model
  which gives some confidence on it.

  The main issue I have is that its visible function is currently
  'static'.  That is, you can't change the data/function for it once
  it's been shown in a tree.  People are certainly going to want to use
  it for 'Search' filters, so this feature might be nice to add.  I'm
  not really sure of the semantics/complexity of this, though.  If we
  want to go this route, it will complicate the code greatly.  Also, as
  a change in the function will result in possibly many changes in the
  structure of the model, we can end up in a somewhat inconsistent state
  in the middle of a signal handler.

  Estimated time to get into GTK+: 1 week, pending dynamic visibility function



Item:     GtkCellRendererPopup
Status:   Partially written
Usage:    Mr. Project
Location: libegg and Mr Project

  This is a combo cell-renderer.  It's been requested a lot, so having a
  cell renderer like this in GTK+ is probably a good thing.  I'm not
  really happy with the behavior of the current one, so it may need some
  reworking.  It may also benefit from the GtkTreeViewEditMode below.

  The other issue involved with this one is that it might be nice to tie
  it's API in with the (currently unwritten) Combo replacement.  This
  may mean holding off on finalizing this until we have a good start on
  that code.  They may not have a lot in common, though.



Item:     GtkNodeState/TreeViewState
Status:   Mostly written
Usage:    None
Location: libegg

  This serializes the state of both the expanders and the column
  positions and widths to a string.  This string can then be saved and
  restored from disk at an appropriate time in an application.
  Additionally, it includes a nice dialog for managing columns in a
  GtkTreeView.

  This code is small and simple, and won't 'bloat' GTK+ by a lot.
  ETable has a similar functionality built in, and a number of
  applications use it.  However, it is very high-level for GTK+, and I'm
  not sure that we want to include it.

  Estimated time to get into GTK+: 2 days



Item:     Multi-row drag and drop:
Status:   Working
Usage:    nautilus
Location: libegg and nautilus
        
  Dave and I managed to get multi-path DnD working for nautilus.  It
  isn't perfect yet, and doesn't cover all possible cases.  However,
  it's a good base to start this code on.

  The primary problem is that the current GtkTreeDnd API only allows for
  dragging one row at a time.  A bigger problem is that the API is
  pretty low level, and that people are having trouble with it.  That
  implies that simply mirroring the current API for multi-dnd maybe an
  inherently flawed approach.  I'd love to get comments on how to clean
  this up from anyone who's used the current DnD code.  This is also a
  no-brainer on putting in GTK+.

  Estimated time to get into GTK+: 2 weeks, assuming the approach is
  good.  Longer otherwise.



Item:     GtkListWrapper
Status:   Written, being refactored
Usage:    Beast
Location: Beast

  This is a simple callback-based wrapper written by Tim Janik for
  beast.  It is similar to the CList in scope -- that is you just create
  it and pack both strings and pixbufs into it.  Given the high rate of
  questions on gtk-app-devel-list about how to use the GtkTreeView, a
  widget like this might be nice.  However, the issues are in the
  details.

  Tim's approach appears to be a callback-based approach.  That is, you
  set the structure of the List/Tree and register a callback for setting
  a string or image when the actual requests for data are done.  It's
  very simple for mapping to a static list of data, or an external list
  of data.

  Another option would be to try to mirror the CList/CTree API as closely as
  possible.  For all it's faults, people are able to figure it out, and
  there is some virtue in keeping the interface similar.

  A third approach would be to make the API as dead-simple as possible,
  but make it obvious how to get the various columns, cells, and models
  out of it.  That way, people could get something visible very quickly
  and extend it as needed.

  Estimated time to get into GTK+: 1 day with Tim's code.  Unknown
  otherwise.



Item:     GtkTreeViewEditMode
Status:   Proposal
Usage:    None
Location: None

  The current edit/focus/selection behavior has the interesting
  property of making almost no one happy.  It needs to work in all
  uses, and thus doesn't work very all when a particular aspect of the
  tree is emphasized.  A proposed solution is to have various behavior
  modes for certain operations.

  For example, if you want to use a list as a DnD source, clicking and
  dragging a row will start a drag.  Conversely, if the selection of the
  list is used to indicate a current state, you would want the selection
  to follow the mouse event (or extend the selection in the case of
  multiple selection).  In the case of some renderers (such as the combo
  renderer), clicking and dragging may result in the popdown of a menu.

  One of the biggest sticking points in tackling this feature is coming
  up with the right semantics and API.  Comments would be greatly
  appreciated.



Item:     GtkTreeView::pack_{start,end}
Status:   Proposal, #70857
Usage:    None
Location: None

  Currently, all remaining horizontal space is used up by the rightmost
  column.  It would be great to be able to pack columns in the view like
  a box to allow for intermediate columns to be allocated extra space.
  It would be very trivial to do this in a backwards API-compatible
  fashion.  Someone just needs to sit down and write all the code to do
  this.



Item:     Column R-L remapping
Status:   Proposal, #50288
Usage:    None
Location: None

  Currently the GtkTreeView really only works in left->right locales.
  It needs modifying for r->l locales.  This isn't hard work, but it'll
  be tedious for whoever does it.  I'm putting it down primarily in the
  hopes that I get a volunteer.

>  LocalWords:  backwards