[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSUser and paths generally
Re: NSUser and paths generally
Tue, 16 Dec 2003 19:25:20 +0100
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Sheldon Gill wrote:
It seems that NSUser.m was originally created by Andrew McCallum for a new
class that handled login related functions.
However, it mainly contains the functions from "NSPathUtilities.h". I propose
moving those functions to a new file "NSPathUtilities.m" where they would
seem more at home.
<disclaimer> I don't consider myself a -base maintainer. </disclaimer>
NSUser.m contains functions associated with the user and his environment
defined in NSPathUtilities.h. There is no such thing an NSUser class.
You are effectively proposing to rename NSUser.m to NSPathUtilities.m.
I'd think thrice before dealing with the issues realted to obtaining the
CVS history for these file just for the functions to be "more at home".
(OTOH, I was the one who moved all the header files a while back :-) )
I guess some administrators may not want users to be able to change the
behavior of their apps by tweaking environment variables, yet
introducing new static search locations like /etc/GNUstep doesn't add to
GNUstep's portability (even if it's ignored when it diesn't exist, we'd
still need an analogous mechanism for other platforms like MinGW other
distros that don't have /etc).
I also propose making some modifications to the path handling routines:
* Initialise the various root directories from a plist in /etc/GNUstep if it
exists, over-riding environment variables. This will allow system
administrators to enforce system file heirarchy policy.
It'll also mean that, on such systems, you don't need to source GNUstep.sh!
* Add support for traditional locations for applications and libraries:
NSApplicationDirectory /bin /usr/bin
GSLibrariesDirectory /lib /usr/lib
NSAdminApplications /sbin /usr/bin
These will be last in the returned array.
* Extend support for more parts of the heirarchy like:
Fonts, Palattes, ColorPanels, Services, etc
What I wish to work towards is making GNUstep highly path layout agnostic and
consolidate it's file dependancies.
This will ease packaging GNUstep for different platforms. I'm particularly
thinking of Win32 but Debian will also benefit quite immediately. Other
things to be done along these lines is extending the defaults system to allow
for installation defaults. This would allow a system administrator to set up
an environment for all users quite easily.
Yet how would you stop a user from using LD_LIBRARY_PATH & co. to
I the available ./configure options of -make together with GNUstep.sh
(sourced by /etc/profile) should give you some freedom to setup a custom
the environment. Yet this does not include putting apps and libraries
in to places not defined by:
Please also refer to the archives (of -discuss I believe) for past
discussions on the topic.
I don't want to block new discussion about the filesystem but this is a
contraversial subject and possibly more apropriate in -discuss (at least
until the positions are clairified.)