On Tue, Sep 22, 2009 at 5:47 PM, John Arbash Meinel <[email protected]> wrote: > I'll just mention that I think there is a strong case for having a WT > widget that acts differently than a RevisionTree widget. Namely because > a RT cannot have any changes, or conflicts, or... Not to mention that > lookups in a WT are often best done by path, while lookups for a RT are > best done by file-id. > > Also, a WT widget should probably be populated by something like > 'iter_changes(include_unchanged=True, include_unknowns=True)', though > I'm not 100% sure how that handles ignored (you probably have to call > 'is_ignored()' yourself on any unknown files.)
qbzr's TreeWiget can show 3 different views: 1. A RT view 2. A WT view that "merges" the data from the inventory, and iter_changes 3. A WT view that just shows changes (Used for qcommit, qadd, and qrevert) I'm not to sure what the use cases for explorer will be, but I think you will be using the 2nd type. The 1st and 2nd types load lazily. So at start up, we only read from the inventory, the children from root, and only when expand a directory when it is expanded by the user. I hope that this will provide good performance for large, deep trees (but I don't expect it to for large, flat trees.) It was in order to achieve this that I "merge" inventory data, and iter_changes data, rather than just calling iter_changes(include_unchanged=True, because it does not allow for me to randomly access a directory. It has to be read in the order that the iter provides. The columns, and context menu items differ between views 1, and 2+3. I hope this blabbering it useful :-) Gary _______________________________________________ Mailing list: https://launchpad.net/~bzr-explorer-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~bzr-explorer-dev More help : https://help.launchpad.net/ListHelp
