[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
From: |
David Ayers |
Subject: |
Re: NSSearchPathForDirectoriesInDomains and non-existing directories |
Date: |
Mon, 24 Oct 2005 13:10:29 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20051002) |
David Ayers schrieb:
> Andriy Gapon schrieb:
>
>
>>In my opinion what NSSearchPathForDirectoriesInDomains() does now is
>>incorrect. I don't have an opportunity to verify how this function
>>behaves in original NeXTStep or how it behaves in OS X framework, but I
>>think GNUstep behavior is unreasonable.
>>
>>I see two possible ways of improving NSSearchPathForDirectoriesInDomains():
>>
>>1. just return the names and let calling code worry if the directories
>>actually exist
>>2. try to create non-existing directories in the list and only if that
>>fails that remove them from the list
>>
>>I personally am torn between simplicity and elegance of #1 and
>>user-friendliness of #2.
>>
>
>
> I remember looking into this exact issue once but I can't remember that
> I came to a conclusion of what "the right thing" to do is.
Nothing is quite as effective at refreshing ones memory as the "send"
button :-)....
Actually the bug is in NSColorList writeToFile: because there is clear
documentation at:
http://developer.apple.com/documentation/Cocoa/Conceptual/LowLevelFileMgmt/Tasks/LocatingDirectories.html
which states:
"However, don’t make any assumptions as to the number of paths returned.
Some domains or locations might be made obsolete over time, or other new
domains or locations might be added (while preserving the older ones);
in either case, the number of paths in the returned array might increase
or decrease. ..."
I suppose that writeToFile:
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSColorList.html
which states:
"If path is nil, this method saves the file as listname.clr in the
user’s private colorlists directory."
should simply return NO in that case.
Cheers,
David