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

[Alexander Larsson <alexl redhat com>]

On Wed, 2003-06-11 at 11:51, Jürg Billeter wrote:
> On Wed, 2003-06-11 at 11:08, Alexander Larsson wrote:
> > On Sun, 2003-06-08 at 16:07, Jürg Billeter wrote:
> > > As a relating patch I've fixed the tree view so it automatically follows
> > > the folder changes in the list view pane.
> > > See http://bugzilla.gnome.org/show_bug.cgi?id=82884
> > 
> > Lets take these one at a time, and start with this one.
> > I'm still not 100% sure the optimal behaviour is to always follow the
> > main view. That can cause problems if you're using the tree as drop
> > target, and have to change the directory of the main view.
> That's true but...
> 
> > However, I've gotten enough complaints about this, and don't personally
> > have a better proposal, so I guess it should go in.
> ...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.

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?
 
> > 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.

> I'll try to update the patch ASAP, probably tomorrow. What about the
> multiroot patch? Shall I update it to reflect the changes in this patch
> or will you comment on it so I can make all changes at once. Would be
> nice if I at least knew what your opinion of the idea, my multiroot
> patch implements, is.

I will comment on the multiroot patch in another mail.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an ungodly vegetarian cowboy on a mission from God. She's a tortured 
out-of-work pearl diver from Mars. They fight crime!