Hello,
at GUADEC I have been discussing with Jonathan (author of GtkTree) about
the possibility of using GtkTree in the GNOME 2 version of Evolution
instead of porting ETable/ETree.
The GNOME 2 port is not in sight yet, but the GTK 2.x schedule seems to
be pretty unmovable and we are in need of some extra features in GtkTree
before the transition becomes possible.
So, I am writing this mail in an attempt to list the things that need to
be hacked in GtkTree before it is feature-complete for Evolution.
My rationale for switching to GtkTree:
* 100% accessible. (If we port Evolution to GNOME 2, we have to
add accessibility support to all the widgets, and making ETree
accessible is a very non-trivial task.)
* Maintainability. ETable is a very complex codebase, and we
still find bugs in it. Switching to a widget that is part of
the platform will hopefully mean less bugs (as the widget gets
more testing from more apps). Also, improvements that we make
to GtkTree will be enjoyed by the rest of the platform and
vice versa. Everyone wins.
* More consistency with the rest of GNOME.
Anyways, before we decide to do the switch, we need to figure out if all
the missing features can be implemented soon enough (I am thinking by
July or so). Here is the list of problems I know of; hackers, please
let me know if I am forgetting anything.
* Better handling of horizontal resizing. Currently GtkTree is
unable to allocate space to the columns proportionally. We
need a mechanism like that of ETable, where you can specify
float values for each column and when you resize the size of
the columns is increased proportionally to those values.
* GtkTree currently spends a lot of time computing the total
width of the table, and doesn't allow a mode where the width
is fixed (i.e. no horizontal scrollbar, like in the message
list). We need a way to specify a no-horizontal-scrolling
mode.
* Status save/load mechanism, for columns and nodes. We need
some way to load and save the status of the widths of the
columns as well as what nodes are open/closed in the view.
ETable currently does that with XML files, maybe we should
keep the same format?
* Column configuration. In ETree/ETable, we can remove and add
columns to the view using DnD. I think GtkTree only allow
moving columns right now, so we would have to re-implement the
"Add Column..." dialog for GtkTree.
* Drag and Drop. Jonathan told me that currently the DnD
interfaces only support dragging one item at a time -- but we
need to be able to drag multiple rows.
Another problem is how we migrate the data models. Jonathan told me
that the GtkTree model and the ETree models are very similar, but we
need to verify that. In particular, we have to see how painful it will
be to port the message list to use GtkTree. (Michael?)
Looking forward to your comments,
--
Ettore
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
