> * 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.
I personally find the add column interface somewhat confusing. > * 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. What about grouping, does anyone use that? Do we even implement it anymore? > 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?) We dont really use the model in that sense for doing much other than string the tree structure, so any tree should do. However, a lot of other stuff is very tightly integrated with etree, such as the sorting/view of the tree, how we iterate through selected messages, and stuff like that. That will probably be a fair bit of work to port. The other thing i'd be concerned about is performance. How well does it handle a tree of say 20K+ messages, and how heavy is it on memory and stuff like that. To thread 20K messages takes in the order of about 1/10th of a second on this box, but building the etree to represent it takes in the order of a second. It has to be at least that fast (ideally it shoudlnt' have to take any more time, but i digress). And can it handle incremental tree changes without bogging down to unusable speed (one thing etree can not)? Are the rows fixed height or can they be adjusted (we currently only really used fixed height cells, but there was always that summary mode people wanted implemented, etc). We'd also be essentially replacing a large body of battle hardened code with a basically untested shiny new implementation which hasn't really had any 'evolution' from living in the 'real world'. And ... wouldn't we be breaking clahey's heart? :) I'm not particularly convinced this is a great idea, though it might be easier than porting etree to gtk2, i guess. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers