[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

[NSColor initialize]
[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]