NSSearchPathForDirectoriesInDomains and non-existing directories
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
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. I don't have OS X but IIRC I was told that the directory was created together with the account. So what ever the behavior is, I guess it can be viewed as undefined as it doesn't really exist on OS X without manipulation of the expected setup. If we chose #1 then it would be the application's (or non-core library's) job to create the directory if it doesn't exist before writing to it. I think that would just push the "bug" to different place. Yet if we chose #2 then we could be cluttering the home directory of say a packaging user who implicitly runs gnustep programs during the build process... But I think we already do that for user defaults anyway and that's what I thought could be handled by setting GNUSTEP_USER_DIR. So I would lean toward #2 right now... but I have a gut feeling I'm still missing some implication. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Andriy Gapon wrote: 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 ? This is the way the function was defined to work a long time ago. In other words, it behaves as specified. The idea in general terms is that you are asking for a location. If that location doesn't exist, it returns rather than an exception. The location may not exist because you're running on an old or new version where it doesn't exist anymore. Things change. Calling code is supposed to know and respect this. 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 think you've mis-diagnosed the behaviour problem. It isn't in NSSearchPath() but rather the calling code. Creation of a path isn't and shouldn't be the responsibility of NSSearchPath(). That needs to be handled elsewhere. Generally it is, by the way. There is some sense in (1) but the question arises: "what do you do when the specified directory doesn't make sense on the current system?" You'd end up needing to handle an exception or error return anyway. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Sheldon Gill schrieb: > > It isn't in > NSSearchPath() but rather the calling code. Creation of a path isn't and > shouldn't be the responsibility of NSSearchPath(). That needs to be > handled elsewhere. Generally it is, by the way. > Indeed there are two issues at hand. 1.) NSColorList has to deal with NSSearchPath returning an empty array. 2.) creating the expected user directory layout, and creating it "in time" for such usage as 1.) which I believe implies: a.) We created it when sourcing GNUstep.[csh] (just kidding :-) ) b.) Creating the directory layout in +[NSObject initialize] or c.) auditing core for NSSearchPath usage and calling an "internal" function/macro to create them just before the relevant invocations. I'm leaning towards b.) as it just seems more straight forward and reliable and I'm not sure whether it's worth while to try to avoid the cluttering. But it would also mean that every little tool will have to at least read from disk to see if the layout exists. I'm not too thrilled about that, but that may already be the case currently wrt user defaults. I haven't had the time to verify that though. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
On 2005-10-25 09:14:04 +0100 David Ayers <[EMAIL PROTECTED]> wrote: Sheldon Gill schrieb: It isn't in NSSearchPath() but rather the calling code. Creation of a path isn't and shouldn't be the responsibility of NSSearchPath(). That needs to be handled elsewhere. Generally it is, by the way. Indeed there are two issues at hand. 1.) NSColorList has to deal with NSSearchPath returning an empty array. Yes. 2.) creating the expected user directory layout, and creating it "in time" for such usage as 1.) which I believe implies: a.) We created it when sourcing GNUstep.[csh] (just kidding :-) ) b.) Creating the directory layout in +[NSObject initialize] or c.) auditing core for NSSearchPath usage and calling an "internal" function/macro to create them just before the relevant invocations. Perhaps there is a reason why directories don't exist ... so NSColorList should recognize that the directory does not exist, and return NO. What about if the directory exists but is not writable? ... NSColorList needs to cope with that case too. So, since code generally needs to be able to deal with error conditions, I'm not sure there is a compelling aregument to say we should force directories to exist by creating them. That being said, I can see how useful automatically creating directories could be, and we could make the behavior configurable. If we are going to do that, the obvious point to do it is when path lookups are initialised (NSPathUtilities.m) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
on 25/10/2005 02:57 Sheldon Gill said the following: > I think you've mis-diagnosed the behaviour problem. It isn't in > NSSearchPath() but rather the calling code. I agree that the code in NSColorList is not robust enough to handle absent ~/GNUstep/Library directory. It should probably simply skip saving color list of NSSearchPath() returns empty array. > Creation of a path isn't and > shouldn't be the responsibility of NSSearchPath(). That needs to be > handled elsewhere. Generally it is, by the way. Maybe there is some tool/routine that automatically creates all required GNUstep directory hierarchy in user home directory ? It would be very convenient for the first-time users of GNUstep. > There is some sense in (1) but the question arises: "what do you do when > the specified directory doesn't make sense on the current system?" I agree that in the case you describe there should be no path returned. But consider the other side of the coin - what if specific directory does make sense but for some reason was not created (as it was in my case) ? We don't even give a chance for calling code to know that path. I think that the logic in NSSearchPath() for determining whether directory makes sense or not based on its existense is flawed. BTW, not that this really makes any difference, but may be of ineterest to you: http://wilshipley.com/blog/2005/10/pimp-my-code-part-5-special-apple.html Regarding: "But, hey, does NSSearchPathForDirectoriesInDomains() actually check to see if the directory it just pointed us to physically exists, or is it just saying, 'Here's the name of the directory, hope that works out for you'?" In my informal tests, it appears that it just spits out the path that the folder should be at. It doesn't bother to check if the folder exists or not. Another link, contains very nice explanation for the function in question (however it does not cover the question), much better than the function's documentation: http://www.wodeveloper.com/omniLists/macosx-dev/2002/September/msg00033.html -- Andriy Gapon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Richard Frith-Macdonald schrieb: > On 2005-10-25 09:14:04 +0100 David Ayers <[EMAIL PROTECTED]> wrote: > >> 2.) creating the expected user directory layout, and creating it "in >> time" for such usage as 1.) which I believe implies: >> a.) We created it when sourcing GNUstep.[csh] (just kidding :-) ) >> b.) Creating the directory layout in +[NSObject initialize] or >> c.) auditing core for NSSearchPath usage and calling an "internal" >> function/macro to create them just before the relevant invocations. > > > Perhaps there is a reason why directories don't exist ... so NSColorList > should recognize that the directory does not exist, and return NO. > What about if the directory exists but is not writable? ... NSColorList > needs to cope with that case too. So, since code generally needs to be > able to deal with error conditions, I'm not sure there is a compelling > aregument to say we should force directories to exist by creating them. Absolutely agreed... > That being said, I can see how useful automatically creating directories > could be, and we could make the behavior configurable. If we are going > to do that, the obvious point to do it is when path lookups are > initialised (NSPathUtilities.m) Maybe I wasn't clear enough, but indeed I meant the initial creation for a user who is starting her first gnustep process/app (independent of the NSColorList issue). How should the expected layout be created? An explicit program he needs to execute (see 2.a. above ;-) ) or implicitly which means each process needs to check if it needs to create them. But, yes, NSPathUtilities initialization is a lot better that +[NSObject initialize]. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
