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

[Seth Nickell <snickell@xxxxxxxxxxxx>]

> I am doing the new Table and Tree, right now concentrating on Table. 
> There are a few subtleties to the SWT API, which were quite a problem
> with GTK1 (e.g., the exact semantics of single-select... we lost count
> how many times we redid it, and even now it's still not *quite*
> right).  As the design of the mapping is going to be non-trivial, I am
> trying to concentrate and get these subtleties right, before we have >
a whole wad of stuff and they cause pain.

It would be helpful for everyone if the target behaviors for each
control were well documented so contributors outside the SWT team could
effectively, well, contribute.

WRT to this specific situation, I would love to work with you to get the
right behaviors. I have a fairly good understanding of GTK and just from
working in related areas of the codebase have seen many occasions where
a little more background experience with GTK could have yielded a much
more satisfactory solution (for example, the current CTree based SWT
Tree's refresh behaviors could have been vastly improved; they are
currently a major performance problem when stepping in deep stack frames
and such). Similarly, you have a good understanding of proper SWT
behavior and experience with previous problems SWT has run into
integrating with GTK.
 
My biggest concern with the TreeView is actually related to refresh
performance. It is *very* easy to use the wrong GtkTreeView APIs and
shoot yourself in the foot performance-wise. Almost every new TreeView
user ends up doing it in some area or another and has to get help (at
which point their techniques are already entrenched, and code
modification is much more painful; as you point out careful advanced
planning can save a world of pain) :-/ Something it'd be really nice to
have in GTK documentation....but c'est la vie.

> So at this stage, the thing is just text-only (no images).  I would
> actually be quite interested to know your approach to having
> "text+icon" cells.  There is no built-in support for this (like a
> provided GType), and while it is easy to write your own using their
> instructions, I find it challenging to do it *AND* obey the SWT rule 
> of "absolutely no custom C code".  You say "image almost work", I take
> it that means you have some code that solves the problem?

My code for display images works... except that Image currently stores
them as Pixmaps and the GtkTreeView requires pixbufs. I'm doing a
brain-dead conversion from Pixmap to Pixbuf on each childitem.setImage
call (and because its not what you'd really want to do I haven't
bothered to include the data from the mask, so areas that should be
transparent are black). The correct solution is either to allow Image to
export both a pixmap and a pixbuf (a little more memory usage, but also
doesnt' require a fairly expensive conversion per-tree-item), or to port
Image to use only pixbufs; which are the preferred Image storage
mechanism in GTK2 anyway. I'd be willing to do this, but was holding off
until I got an "ok lets do that" from SWT folk.

I'm not sure what problem you are running into. My guess is that you
aren't aware that multiple cell renderers can be placed into a single
column.

Here's a basic top to bottom run-down of how the TreeView is structured
(the docs need something like this, sadly they don't really have it):

A GtkTreeView contains a certain number of GtkTreeViewColumns. It uses
various heuristics (including but not limited to fixed size) to
determine the widths of various member columns. In turn, columns have
one or more GtkCellRenders placed in them in a particular order
determined by packing. Each cell renderer is then requested to render
its section of the cell upon request. CellRenderers in turn have one or
more properties associated with them that they can use to access data
from an appropriate column in a GtkModel.

A GtkTreeStore or GtkListStore (obviously you can write your own) fills
the GtkModel interface. The models can have an arbitrary number of
columns of different GTypes. These do not necessarily map in any way
shape or form to actually viewable columns. Data gets set through the
store interface (since there is extra metadata which can be set custom
to each store), and retrieved through the model interface.

John's "letting" me divert a couple days of work to this rather than
focusing on what I'm "supposed" to be doing ;-) Today I'm finishing off
implementation of the remaining few Tree APIs like "expand to node" that
I have yet to write, and then I'll send you what I've got. At this point
the only major bug that I'm aware of is with the Pixmap stuff, which
requires slightly broader SWT changes.

-Seth