Re: [Nautilus-list] Can't write emblems

[Darin Adler <darin bentspoon com>]

on 10/5/01 12:35 PM, Alex Larsson at alexl redhat com wrote:

> Here is a patch that cuts down on the amount of can't write emblems.
> You only get an emblem for files that you can't write to if you can write
> to the directory the file is in. It does make the can't write emblem much
> more useful in my opinion.
> 
> I'm not sure this patch is enough, considering the async nature of
> NautilusFile. Don't i need to somehow update this when the parents
> permissions are loaded?

I have three comments here:

First, when I was thinking of fixing this, I was going to leave out the
can't write emblems in context in the directory view because they are
showing as children of the parent directory. When showing the emblems alone,
or when computing the emblems for "sort as emblem", I was thinking we would
still include the can't write emblem. So this would be a special case in
FMDirectoryView, not in NautilusFile. We could have other "relative emblems"
that show up only when they differ from the parent if we want.

Second, you are astute to point out that there's nothing here that will
cause the NautilusFile to notice a change when the parents permissions
change. "Being loaded" is just a special case of a change in permissions.
There are two things to get right -- emitting the appropriate change signals
and making sure the cached data in the NautilusFile objects gets updated.

Third, there's nothing here to cause the parent to do the appropriate I/O to
make the can_write attribute correct. So if someone gets a file and tells it
to get information about the emblems, we'd have to make the parent
directory's file also get the information needed to make can_write accurate.

Note that my second and third comments are not an issue if this is done at a
higher level, which is an argument in favor of doing this at the
FMDirectoryView level.

    -- Darin