Re: NSPathUtilities Patch

[Wim Oudshoorn]

I have looked shortly at your patches.   
So I have not a really clear idea where this is going, but
I don't think the patches are in a state yet that they
can be applied.  My concerns are on a detailled level
as well as on a more philosphical level.

Detailed level
--------------
* Patches introduce quite a lot of outcommented code
* Introduce a few functions that are not used anywhere
* Make new header files public without apparent reason
* Put lots of #pragma mark - code in files (what is it
        anyway?)
* Why do most new win32 functions take a cString as 
        argument ant return an NSString, instead
        of taking an NSString
* Why do you call CoCreateInstance in the Win32_Utilities_init
        function.  It seems to initialize the windows COM
        system, but what does that have to do with GNUstep?
* Why do you expect these windows functions to be needed
        from "gui" as well?
* Capitalization is inconsistency, test_assign macro is
        only lowercase
* I think there are retain count problems in
        InitialisePathUtilities,
        gnustep_rc_filename is set to the value of
        objectForKey:, while os_sys_prefs is set to
        objectForKey: but retained.
* Probably more, but I stopped looking


Higher level
------------
* If you want to get rid of the necessity to specify
        GNUSTEP_SYSTEM_ROOT and other environment variables.
        Why not figure out the path of the gnustep-base.dll
        (or on linux libgnustep-base.so) when starting up
        and use that as a reference point to provide
        default values for the paths.

* What is the idea behind the PLATFORM_... paths?
        It seems to me that this will lead to 
        different behaviour on different platforms.
        I do not think it is desirable to provide
        something that only works differently
        on different platforms.  

* In the same category, the NSTemporaryDirectory change.
        It should be clear what the programmer can
        expect from this path.  And it should be the 
        same on all platforms.  (or as close to same
        as possible.)  I think it does this, but the
        sentiment in the documentation that if you
        want the old behaviour there are workarounds
        is not very encouraging.

To consolidate my take on it.
GNUstep should be as platform independ as possible, that
means, NO visibility to the programmer of platform specific
options.  The programmer is of course free to use platform
specific stuff, but it should not be provided by GNUstep.
        
This is not to say that I really would like to see a better
approach to the startup/installation of GNUstep.  
But I agree with other people on the list 
that it should be split in independ patches.


Wim Oudshoorn