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

[Alex Larsson <alexl redhat com>]

On Fri, 5 Oct 2001, Darin Adler wrote:

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

Yes. This makes much more sense to me. I was slightly worried that the 
sidebar didn't show a can't write emblem for e.g. /usr with my patch.
 
> 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.

I understood these issues, I just don't know how to implement it.
 
> 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.

Great.

/ Alex