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

From: vais <vsalik....at.gmail.com>
Date: Sat, 14 Feb 2009 18:18:11 -0800 (PST)

Just to explain my last point a little better: if get_contents_for
could return a table AND optionally its tree state, it would make it
possible for the file browser to maintain a separate table where keys
are root strings (e.g. "/", "/Users/vais/projects/my_project_folder),
and the values are serialized states that were saved when
"textadept.pm.activate" was invoked with a different
textadept.pm.entry_text.

So, do you think textadept.pm.activate could be the hook you are
looking for? It would remember the last activated browser and ask it
to save its state before activating another one.

Other than that, I give up... I may be completely off the mark -
perhaps you could explain the problem a little more in-depth?

Thanks,

Vais

On Feb 14, 8:11 pm, vais <vsalik....at.gmail.com> wrote:
> Mitchell,
>
>
>
> > 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
> times:)
>
> 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 textadept.pm.get_contents_for 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 :)
>
> Vais
>
> On Feb 14, 7:09 pm, mitchell <mforal.n....at.gmail.com> 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 'textadept.pm.cursor'
> > 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 - 21:18:11 EST

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