Re: [PATCH] Add more nautilus_file..._nocopy variants

[Federico Mena Quintero <federico ximian com>]

On Tue, 2005-12-06 at 10:45 +0100, Alexander Larsson wrote:

> Yeah, this is the right approach, measure first, then fix. Of course,
> having spent a few years doing this I know its not as simple as you'd
> think. :)

Yeah, I can imagine.

Do you know if the descriptions under nautilus/docs are up to date?  I'd
love to see a diagram or something about the multiple layers of
asynchronicity.

> The asynchronicity makes concepts like "finished" hard.
> fm_directory_view_end_loading() might be a good point though. We
> continue to do low-prio dynamic updates after it, like updating deep
> counts for folders, but at this point the user can start seriously using
> it. I'm not sure that includes all displaying though, some painting
> might be done in idles. You need to test it out.

Yeah, we'll need to figure out a way to checkpoint when the initial
display is done.  We can probably have a boolean flag on each view which
says whether it has been laid out initially or not yet.

> What are you trying to optimize? New window speed? Cold-cache case or
> hot-cache case? Have-to-sniff case like /usr/bin or an easier case where
> all files have extensions?

New window speed ("double click a folder icon"), hot cache for now.  We
can't comfortably test the cold cache case until the kernel gives us a
good way to wipe the buffer cache.

/usr/bin is a stupidity in xdg-mime, I think - it should have heuristics
like the old MC had for files without extensions:  if a file is +x and
has no extension, it's an executable, period.  We can probably have a
flag to say "but it is ambiguous", and do a sniff in really-low-priority
stage.

The people at Sun are doing some Dtrace action on various parts of the
desktop; let's see if they report anything on Nautilus :)

  Federico