[platform-swt-dev] GTK2 Tree/TreeItem conversion

[Seth Nickell <snickell@xxxxxxxxxxxx>]

Hi,

GtkCTree was making my eyes bleed, so I threw together a version that
uses GtkTreeView (well, actually a GtkTreeView, GtkCellRendererText,
GtkCellRendererPixbuf, GtkCellRendererToggle, GtkTreeStore,
GtkTreeModel, GtkTreeViewColumn and a GtkTreeSelection.....could the Gtk
team have made it any more complicated? *wink*).

Working: 
   - basic tree functions work (expanding, collapsing, selection,
clicking, selecting-by-cursor etc)
   - pixmaps mostly work
   - checkboxes work (*real* checkboxes, not little images).
   - Its quite usable within Eclipse, tried a bunch of different places
that use a Tree

Problems: 
   - pixmaps are not masked so they are black where they should be
transparent. This is because we are using GdkPixmaps internally rather
than the preferred in GTK2 APIs GdkPixbufs (and then new GtkImage rather
than GtkPixmap). I think the easiest solution is to convert internally
to Pixbufs and I'm willing to do this if I here a "yes we'd like that";
we're using a pixbuf in the constructor anyway and only converting to a
pixmap at the end. The other alternative is to convert both the bitmap
mask AND the gdkpixmap to a pixbuf and do the masking manually. Gross,
and slow.

  - Expanding requires "two clicks" currently in many tree views. This
is probably a result of unhappy interactions with the JFace model/view
code. What happens is that when you expand the first time it tries to
expand, waits a short period, and gives up. By the time you click again
the model is loaded in JFace and it expands ok. The new tree view is
model-view based, and may well be giving up on waiting for the JFace
model. Need to figure out a way to tell it to "wait" for our rather slow
client before expanding (though ideally we would actually be able to
directly touch the JFace model and not have a mvc control pretending to
be a dumb control so it can interface with another model; but that would
require API changes and lots of work).

  - We're allowing a few Null pointers to slip to Gtk and a bad iterator
here and there; probably a bug in a single place; so GTK throws some
warnings.

I'll try to fix some of these, though I should be moving along to other
tasks fairly soon. I'll probably not do GtkCList, but it should be
pretty easy to do using the techniques in Tree as an example (and of
course the few dozen JNI calls that had to be added).

-Seth