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

[Jürg Billeter <j bitron ch>]

On Sun, 2003-06-15 at 16:10, Alexander Larsson wrote:
> On 15 Jun 2003, Jürg Billeter wrote:
> 
> > We're still undecided but I've made a new set/variant of patches.
> 
> You don't need to compare uris of files, NautilusFile have a one-to-one 
> mapping to uris. I.E there is only one (shared) NautilusFile for each uri. 
> So for instance in show_iter_for_file you only need to compare the 
> pointers to the nautilusfiles.
Nice to know. Once (in the multi-root patch) I just need to compare the
beginning of the uri but that's anyway not good as it is now. I'll need
to figure out a nautilus way of doing this.

> Do you really need the NautilusTreeModelRoot object? Can't the 
> file_to_node_map hashtable be a file->list of nodes? That way you avoid 
> a NautilusTreeModelRoot pointer per object. Also you'd only need one 
> changed handler etc.
That wouldn't work like that as it sometimes only need the corresponding
node of the same root. But if the nodes don't have a pointer to the
root, how to distinguish them? Perhaps there is yet another solution but
I don'it know any.

> When expanding a path to a file that is in several roots, should we really 
> select the root where the selection is? I think expanding the root that is 
> "closest" to the file is better. That means e.g. the floppy root is 
> expanded instead of /mnt/floppy in the filesystem root (if the file is on 
> the floppy that is).
It doesn't just take the root where the selection is. The basic
principle is to take the root which has the closest visible folder but
if there are two roots who have same close folders, it prefers the root
where the selection is. I thought that this would be the most intuitive
solution because it only deviates from your solution if the user already
has expanded other "close" folders and this should help against some
cluttering. If it wouldn't prefer the selection's root there is at least
one situation where the user could get confused:
A user has expanded his /home/<username> folder in the filesystem root
instead of the home folder root and also clicked (to navigate to) on his
home folder located in the filesystem root. At next, he doubleclicks in
the main view on a subfolder of his home folder and expects the tree to
select one of the already visible folders. But no, the tree would expand
his home folder again but this time the home folder root and select the
subfolder there. Oh, that's badly explained, I hope you even tough have
caught the idea.

> Are we always sure we get the row_deleted callback after all the files 
> have been read in? Maybe piggybacking on done_loading is better?
Mostly but during my testing I have catched some cases where it didn't
get the row_deleted callback, but it only occured with multi-root. I've
tried some other things and then found a solution that works with the
row_inserted callback and this works always (at least in all my
tests...). It's implemented in the 3rd patch, but I haven't "backported"
it to the first patch.

> code style:
> no // comments
> use foo_bar instead of fooBar
Ups, got my different coding styles for different projects mixed up.

BTW: I've just found three forgotten-to-delete code lines
(s/^.*uri.*$//) in the multi-root variant of show_iter_for_file that
leads to a crash if you navigate to a location which has no tree root.

I'll update my patches to reflect the spoken-of bugs. Shall I try to go
on with context menus and things like that, so one can get an idea how
it possibly will be in the end or shall I wait until it's decided what
variant will go in?

Have a nice GU4DEC

Jürg