Re: Preserving the File Browser tree state when switching PM Browsers

From: vais <>
Date: Sat, 14 Feb 2009 17:11:51 -0800 (PST)


> This defeats the purpose of the side pane ;)

I see what you mean - this could be accomplished with a plain old
buffer (that takes me back - I remember the first "project manager"
you made for Scite-tools that was entirely text-based - oh, the simple

I do not completely agree, though - it could work very nicely: I mean
the buffer list is not a tree. Imagine something like that, where some
items could have a folder icon and others the file icon. Click on file
to load buffer, click on folder to drill down. To go back, click on
the special solder at the top that takes you up one directory. It is
not fancy, but it can work.

That said, I would of course much prefer the convenience of a tree and
being able to see the big picture. I agree, b) is more elegant, but I
am not sure I understand the problem though - is the issue detecting
when one browser is unloaded and another one loaded? Could this be
done in where it interrogates
pm.browsers for a match?

Also, not to make matters more complicated, with this approach will it
be possible to have multiple states for the file browser based on
different root strings? This is what I am ultimately after - being
able to drop in multiple directories via add_browser, browse inside
each and be able to switch from one to another, with each one
preserving its state.

Not sure I have been very helpful at all, sorry :)


On Feb 14, 7:09 pm, mitchell <> wrote:
> Vais,
> > 1. Abandoning the hierarchical browser idea in favor of a flat one
> > with a ".." parent directory pointer for navigation (double-clicking
> > on a directory changes to that directory).
> This defeats the purpose of the side pane ;)
> > 2. Adding more functionality to support preserving tree state. This
> > can be done in one of two ways, both of which involve adding support
> > for another key in the tree data table:
> >   a) "children" key that contains a table of children that may in turn
> > have their tables of children ad infinitum.
> This could be costly in terms of memory. Not sure how this would be
> implemented in C anyway seeing is how it would have to know where to
> look to find children.
> >   b) "expand" key, which is a boolean value. When tree data is loaded,
> > if "parent" is true and "expand" is true, get_contents_for gets called
> > right away without user interaction, and the node is presented as
> > expanded in the tree.
> This is the best option so I worked on it for a bit and came up an
> elegant solution that needs its own elegant application (which I have
> yet to come up with). We can use the existing ''
> field to save and reload the view state. Since it doesn't work like
> this in 1.4, I had to tweak the existing code for a multi-depth path
> so parent rows are automatically expanded. It works now, but I don't
> know how to apply it. Obviously the cursor needs to be saved when
> changing to a different browser and then restored coming back. I'm not
> sure how to detect these events though. Any ideas would be helpful.
Received on Sat 14 Feb 2009 - 20:11:51 EST

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 11:37:21 EST