Since it's not possible to pickle the TreeStore, I think perhaps I'll experiment with separating the entire mass of the data from the TreeStore. I'll use a dictionary (or a similar data structure that's suitable for sorting and searching) to hold the data (call this "EntireData").
I'll continue to use the standard TreeStore attached to a TreeView, but keep only a small portion of the entire amount of data in this TreeStore - that is, keep only the subset of EntireData that is visible to the user given the dimensions of the widget and position of the scrollbar.
This means that I must explicitly alter the contents of the TreeStore whenever the user moves the scroll bar, specifically :
when user moves scroll bar (determined by setting up callbacks for the relevant signals), do :
- determine range within EntireData based on position of scrollbars.
- TreeStore is cleared and re-filled with that subset of EntireData that is within this range.
In fact, if the user scrolls down or up by clicking the arrows, only two alterations are necessary on the TreeStore, rather than a complete clear and re-fill. For example, if the user clicks on the down arrow the next element in EntireData needs to be added to the bottom of the TreeStore, while the uppermost element of the TreeStore can be deleted.
One drawback of this approach is that the size of the scrollbar will not accurately reflect the size of the EntireData : the user will have no visual cue to the actual range of the data, (unless of course I figure out how to manually set the size of the scrollbar. :) )
Does this sound like a reasonable alternative solution to the problems that Don was having with subclassing GenericTreeModel?
Eugene
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
