Re: Incremental loading of directory contents

[Alexander Larsson <alexl redhat com>]

On Sat, 2007-11-03 at 23:10 +0100, Bogdan Butnaru wrote:
> Hello!
> 
> As I said in a previous mail, I'm working on improving the way
> Nautilus displays icons in the file manager. I'd like to constrain
> myself as much as possible to
> libnautilus-private/nautilus-icon-canvas-item, but I'm hitting some
> interdependencies with the nautilus-icon-container (in particular, it
> expects to finds the icon text in some specific positions).
> 
> I'm going to do everything for now to keep the way
> nautilus-icon-container works, but in the future I'd like to change
> that, too, and I was wondering if someone can guide me towards that.
> We can take the discussion off this list if you think it's better, it
> might become long (I'd like to experiment with a lot of different
> icon/folder layout methods).
> 
> Some things I'd like to try (I expect all of these would get in
> "production" Nautilus, but tell me if something seems unreasonable)
> are listed below, and I'd like some input. The overarching goals are
> (a) compact and quick display of folders and (b) good-looking folders.
> 
> 1) (very) different ways of placing icon labels: RTL/vertical text, on
> any of the icon's sides, depending on the label's content (size and
> script, I think), and on the user's preference.
> 2) Point (1) means that at least some of the folder layout options
> become harder, so I'll have to change that too, at least for some
> layout types (icon/list, tight/regular).
> 3) Nautilus is very slow in some ways I use it (big folders, thousands
> of items), and (1) will make an individual icon's layout time a bit
> longer, so I'd like to understand how Nautilus lays out a folder and
> try to make it "incremental". In particular, I'd like to change all
> the icon layout algorithms (point 2) so they only need to look at the
> icons in the window.
> 
> The last point is the most difficult. I'd like to get some input from
> whoever knows most about that part to see how feasible that is. If you
> don't care much about what I've said until now, you can stop reading.
> Below I'll continue ranting a bit about what I've been thinking
> of/trying until now:

I'm sort of busy with the nautilus-gio work, so I can't go into details
about this (need to finish the work for Gnome 2.22, so other things are
a bit on backburner), but it sounds like interesting ideas where I think
Nautilus can be improved. Here are a few things that came to mind
scanning your mail:

You can't really expect to only modify nautilus-icon-canvas-item. The
icon view really is built on a couple of classes (NautilusIconContainer,
NautilusIconCanvasItem, FMIconContainer, FMIConView) and these go
toghether in a sort of tight way. In general its better to get a view of
how all these fit together and modify that as if it was one "widget"
rather than doing separate work on each class. 

I don't think the icon view code is especially nicely laid out, in fact
I think its overly complicated and not the way I would do it myself, but
its what we have... I have at times pondered doing a complete rewrite of
it, but that has not happened yet.

For RTL layout there has been some work here:
http://bugzilla.gnome.org/show_bug.cgi?id=342009

About incremental layout... Its a good idea in theory, but in practice
it tends to not work out that well. In fact, nautilus stated with
loading directories in chunks and layouted and displayed them while
loading (its probably easy to make this happen again, since the
disabling of that was just avoiding to do layouting before we've gotten
all files in the dir, see somewhere around display_pending_files in
fm-directory-view.c). The main idea with incremental loading is that if
we start laying out early, before getting all the files then the user
can start using the window before its fully loaded, and with luck the
files he wants to work on is amongst the first files. 

However, in practice this doesn't work, becase in almost all cases the
window is in some sort of automatic layout mode (sorting generally).
This means that each chunk of files that get added to the window will
rearrange the visible icons (if new files are added in the middle, or
before the visible part). So, the user can't do anything with the icons
anyway until they have stopped "jumping around". Otherwise its likely he
would just click on the wrong file due to an icon moving. Furthermore,
since users have to wait anyway, doing incremental layout like this is
actually more expensive (O(numfiles) sorts are needed instead of just
one) without actual gain, so it causes slower load times.

Do you have a different idea how this could work that avoids these
problems?

About laying out horizontally (i.e. 'like windows explorer'), there has
been several requests about that, and for large directories it seems
like a good layout. We should at least support this optionally.