Thread: [java-gnome-hackers] More thougths about TreeView and related

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi!

Some more thoughts about TreeView and related widgets

1. I've noticed you have implemented TreeModel as an
abstract class instead of an interface. In my opinion
this is a good design decission. However, I don't like
one things, the dispatch function and its ugly "if
(this instanceof XXXX)". It would be much better to
have a protected method and let its subclasses
(ListStore, TreeStore...) overwrite it (Object
Oriented way!!). See attached patch.

2. A problem of the TreeModel as abstract class design
is that it allows users to call setValue() on
TreeModels that do not have such method, for example
TreeModelFilter, of course getting the
UnsupportedOperationException. I wonder, however,
whether we could implement dispatch() in such models.
For example, in TreeModelFilter we could delegate the
operations in the base model easily. What do you think
about this?

3. I've noticed TreeSortable interface is still not
implemented. Is it by design, or just missing
coverage? At a first sight, it seems setSortColumn()
in TreeViewColumn is enought to sorting. However, this
do not allow us to sort elements in a ComboBox, for
example. And there is a missing feature: the
gtk_tree_sortable_set_sort_func(), very useful for
handling non-trivial sort in an easy way. For example,
think again on my "nautilus" example. When sorting
files by name, usually folders are show before files.
In the same way, when sorting by size, we want to sort
by the real size (a long) and not by the String size
we need to use to show the size. Both cases are much
easier of implement with a custom sort function. In my
opinion, this should be exposed using
java.util.Comparator<TreeIter> interface, and of
course implemented internally using our signal
handling system. I'd like to implement this, but
please give me you opinions.

4. DataColumnPixbuf has a bug. Its type should be
GDK_TYPE_PIXBUF, and not G_TYPE_OBJECT as it is now.
With current implementation you get a

(java:6304): Gtk-CRITICAL **:
gtk_icon_view_set_pixbuf_column: assertion
`column_type == GDK_TYPE_PIXBUF' failed

when used with a IconView. The solutions is quite
easy, but requires to change Value implemenation. So
here comes the question, where to add the new Value
constructor? Make it sense to add a gdk.Pixbuf
dependence in glib.Value? Should I code it in
gtk.Value instead?

5. GtkCellRendererPixbuf can render a Stock icon via
the stock-id property, that is a gchar array. However,
currently only a Pixbuf can be renderer with our
CellRendererPixbuf. What about adding a new
DataColumnStock? And what we should do? add a
setStock(DataColumnStock) to CellRendererPixbuf, or
either create a new CellRendererStock that obviously
maps to a GtkCellRendererPixbuf? Opinions?

Cheers,
Vreixo

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