Re: Patches improving tree view (multi-root and auto-follow)

[Jürg Billeter <j bitron ch>]

On Wed, 2003-06-11 at 16:09, Alexander Larsson wrote:
> On Wed, 2003-06-11 at 15:56, Jürg Billeter wrote:
> > On Wed, 2003-06-11 at 14:05, Alexander Larsson wrote:
> 
> > > As roberto pointed out, this change pretty much forces you to use
> > > multiple windows to copy files using drag-and-drop. That is a huge
> > > change for the users that currently do that using the tree view.
> > 
> > > The main use cases i see for the tree-view is:
> > > a) quick browsing for a specific directory. select it and it loads in
> > > the main view.
> > > b) drag-destination for file copying. Position the tree in the right
> > > place, navigate the view to the source directory and dnd the files.
> > > 
> > > For both these operations the current behaviour is pretty much optimial.
> > > What are the operation you want the tree-follows-view behaviour for?
> > > 
> > > maybe:
> > > c) copy files to the parent directory of the directory they're in now
> > > d) get an idea of where in the tree the current directory is.
> > > 
> > > Is there anything else? And is there a possible behaviour that allows
> > > that operation but doesn't break the other?
> > e) switch quicker between the current and an other directory while
> > keeping the overview where in the tree both directories are
> 
> Hmm. I don't see what tree-follows-view gives you here. Could you give
> an example?
Imagine you have two directories which aren't that near in the tree (so
not just a simple "up" or something like that away) and you need to
change between this directories often (for example you have a project's
source directory and a public_html folder or something like that).
Without tree-follows-view you have to expand the corresponding nodes
yourself of both directories yourself. With tree-follows-view you just
change once to the other directory and both directories will be visible
on the tree where you can switch between them relative quickly. Sure,
you could use symlinks but perhaps you don't want it like that.

> > I have two ideas that probably don't break both uses or at least not
> > that much.
> > 1) Default behaviour as it is now (without my patch). Add a button "sync
> > tree view" or something like that - this button is _not_ an option
> > toggle, it is a one-time sync. I've already seen something like that in
> > IIRC help browsers, perhaps a version of MS' Html Help. A must - if this
> > idea gets implemented - is an easy keyboard shortcut, perhaps an F? key.
> > Almost no cons except changing habits for previous users of almost any
> > other file manager.
> > 2) That's a more in-depth change for previous users of Nautilus but
> > perhaps it's not that bad. Behaviour of the tree is to follow the
> > current directory. Add a "Links" or "Bookmarks" toolbar where one can
> > drop folders (dragged from tree or from list view). Now the user can
> > drop files or folders on the folders in the toolbar. If you click on a
> > link you will be redirected, of course. If one doesn't need a link or a
> > bookmark anymore, one can just drag it out of Nautilus' window and the
> > link will get deleted. This could be really helpful if you need a
> > directory often. And the purpose of the current tree view is almost
> > replaced. The only con I see (beside being a deeper change) is that one
> > doesn't have an idea where in the tree the bookmark folders are.
> > 
> > Just two ideas, I don't know what the two groups of tree view users'
> > opinion on these is.
> 
> I also would like some other users opinions on this.
BTW I personally would perhaps vote for a combination (1 + bookmarks
toolbar) as the bookmarks toolbar is like an additional feature, it
doesn't need to change the tree-follows-view behaviour.
What's your opinion?

> > > I see. However, I don't know if an idle loop is the best way to do that.
> > > The idle handler may run quite a lot before the parent directories have
> > > all loaded. This is very close to busy-waiting. Perhaps there is a
> > > better way to wait that just wakes up once at the correct time.
> > 
> > Hm, yes, perhaps we could catch the row_deleted signal of the tree model
> > and check if it's the dummy row which got deleted. Does this sound
> > reasonable?
> 
> It does sound reasonable, but I don't know the tree model code that
> well. I think you'd have to try implementing it to see if it works.
I'll probably try that in the next days.

Jürg