bzr-explorer-dev team mailing list archive

[Gary van der Merwe <garyvdm@xxxxxxxxx>]

On Tue, Sep 22, 2009 at 5:47 PM, John Arbash Meinel
<john@xxxxxxxxxxxxxxxxx> 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