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

[Jürg Billeter <j bitron ch>]

On Wed, 2003-06-11 at 14:05, Alexander Larsson wrote:
> On Wed, 2003-06-11 at 11:51, Jürg Billeter wrote:
> > ...that shows that this is the expected behaviour.
> 
> That is not at all certain. Nobody complains to me about a behaviour
> that is right for them until we change it. Then I get a billion
> complaints from the people who use Nautilus in a different way than the
> people who complained before. This is the problem with behaviour
> changes, and its very hard to get behaviour right for all users.
Agree.

> 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

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 must say i don't quite understand this later part. If the specified 
> > > file somehow didn't exist in the tree we show it anyway? When does this
> > > happen?
> > 
> > I really should have commented that...will probably do that. The
> > explanation: The for loop checks if the file exists already in the tree
> > as a direct child to parentIter. If it does not exist, the reason is
> > that the parent is not yet expanded. So we will expand the parent so the
> > child shall show up. But as the expansion works asynchronously we need
> > to wait a bit (so we pause a moment until the
> > updating_selection_idle_callback is called again). I hope it's clear now
> > even in my non-native English. Else please ask again.
> 
> 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?

Jürg