[java-gnome-hackers] Thoughts about TreeStore

[Vreixo F. L. <met...@ya...>]

Hi!

During my work on TreeStore I've faced some problems I
want to discusse with you.

First of all, there is the model field in TreeIter. It
has a problem. Signals like TreeView.ROW_EXPANDED
return a TreeIter, which is instantiated by generic
signal handler that, obviously, do not know how to
initialize the model field. With a simple
implementation, this converts the TreeView parameter
on the signal handled in a completelly useless
parameter. The solution I've taken is add a package
protected setModel to TreeIter, together with removing
of the "final" qualifier in such field. That way, we
can implement a custom signal handler (of course,
private and hidden to the user), that initializes the
missing model field (see attached treestore.patch).
Ok, solved in a quite good way. But a bit ugly, sure.
The model field increments the implementation effort.
Not a problem, actually, if such field really provides
a better API. In my opinion, this is the case. Having
an iterNext() without the need of a model parameter is
sure a good thing. However, given we need extra effort
to have the model parameter in TreeIter, why don't we
take more advantage for each. Of course, I'm
presenting again my old proposal for having the
setValue/getValue function in TreeIter instead of of
TreeModel (see attached itervalues.diff).
This allow to set values of a row without having the
model, and it is useful, for example, to access the
values of a row in a signal handler without needing to
take a reference to the TreeModel. It is already on
TreeIter? Why force users to add extra code to get it?

------

Another question is the way CellRenderers are created.
They always take a CellLayout (ie, a TreeViewColumn)
as a parameter. I'm not against this, but what I don't
like is that they're always added to the given
CellLayout with the expand property set to true. Maybe
I'm missing something (help me!), but it seems it
can't be changed later. If so, this is a design
pitfall. Reason? Think about the left panel of an app
like nautilus (the tree of directories). It is a
TreeView with a single TreeViewColumn, with two
CellRenderers, one for the icon, one for the directory
name. If we set the expand property of the icon to
true (as it seems forced by java-gnome), when the
TreeView gets expanded it appear an ugly white space
between the icon and the dir name. This is ugly. How
can I handle this properly? Is it possible with
current design? If not, we should change this, maybe
with an alternate constructor that takes an additional
"boolean expand" parameter.

Cheers,
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/