[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NSSearchPathForDirectoriesInDomains and non-existing directories
From: |
Andriy Gapon |
Subject: |
NSSearchPathForDirectoriesInDomains and non-existing directories |
Date: |
Mon, 24 Oct 2005 11:26:27 +0300 |
User-agent: |
Mozilla Thunderbird 1.0.7 (X11/20051016) |
Let me shoot the question first - what is the rationale behind
NSSearchPathForDirectoriesInDomains not returning directory name if the
directory does not exist ? Esp. so if NSUserDomainMask is used ?
Now the background - I never used GNUstep environment before, but now I
am porting to FreeBSD a graphical linux game that uses GNUstep
framework. Initially I observed some very strange behavior from the game
and my only clue was the following debug message:
NSImage: compositeToPoint:fromRect:operation: failed due to ...
(I don't remember the exact ending of the message and I am a bit
reluctant to reproduce the problem now).
After some debugging I determined that the cause for the error was that
NSImage class was not completely initialized because of an exception in
initialize() method at the following line:
clearColor = RETAIN([NSColor clearColor]);
Then I determined that the exception actually came from initialize()
method of NSColor class and tracking its origin I determined this call
chain:
[NSColor initialize]
initSystemColors()
[NSColorList writeToFile]
And the exception comes from these lines:
path = [[NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,
NSUserDomainMask, YES) objectAtIndex: 0]
stringByAppendingPathComponent: @"Colors"];
and the reason for it was that I didn't have directory
~/GNUstep/Library, so NSSearchPathForDirectoriesInDomains() returned an
empty array, which apparently was never expected, so objectAtIndex failed.
Now I am not really sure if the subsequent code in writeToFile() is
capable of tolerating non-exsiting user library directory, but it didn't
even have a chance! Because NSSearchPathForDirectoriesInDomains()
decided not to reveal a name of requested directory.
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.
--
Andriy Gapon
- NSSearchPathForDirectoriesInDomains and non-existing directories,
Andriy Gapon <=