[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple changed documentation for -[NSString stringByExpandingTildeInP

From: Richard Frith-Macdonald
Subject: Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
Date: Tue, 10 May 2005 08:22:24 +0100

On 2005-05-10 01:07:00 +0100 Sheldon Gill <address@hidden> wrote:

I'm working on string methods now as part of my path & win32 effort, if anyone is interested.

I'd be interested in knowing what exactly .... as I have a load of uncommitted windows path changes on my system (I was waiting for feedback on the last tranch of changes), and I'm also occasionally updating bits and pieces to match MacOS-X API.


In no particular order and off the top of my head:

* NSHomeDirectoryForUser() now finds other users on Win32

* Additional directory keys for NSSearchPath() including
  all the new Tiger keys.

* GSSearchPath() for porting/compatibility

* New implemenation of SearchPathForDirectories; O(1)
    Very much faster and more readily extensible

* Paths from registry in Win32 for mingw32 native

* standardised, improved way to determine win32 IsExecutableFile

* hide/show extensions on win32 in sync with Explorer

* Flexibilty improvements in FS layout for platform-specific packaging
  Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}

* Some string methods do better argument checking and/or raise an
  exception when invalid/nil

* Documentation for all this and more

Wow ... that's a lot of changes.

Still progressing

* Path handling fixes in the rest of base and gui: where we have
  assumptions about layout which are no longer valid or where
  the code can be cleaned up

* More and better use of Unicode and Win32 api. We should be
  using either Step or native methods as far as possible to
  improve behaviour. This will be ongoing for a while...

* Framework support on win32. With my _find_framework() in NSBundle we
  can now properly locate the framework directory and so know exactly
  where the DLL is. We can load it explicitly when needed.
  Its a case now of linking and symbol resolution.
  A ways off (because of time)

Please could you submit individual patches for each of these dozen or more changes? If we get individual patches over a space of time as they are developed, we can integrate them into GNUstep promptly ... which is definitely not the case if we get a few large patches at once. Larger and more complex patches take a long time to review, and have to wait for people to have that time available ... which can mean that improvements which could have been immediate take many months (perhaps so long that they become irrelevant/unusable) to become available.

* Remove PathHandling mode

I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.

As you know, we had much discussion about path handling, and there was definitely no consensus ... so the current code is a compromise allowing the various viewpoints to be more or less satisfied, and switching of modes during runtime was purely for testing that. I think the aim is to move to the 'do the right thing' mode once people are generally happy (though perhaps mode control on process startup using an environment variable will be supported).

Currently, it's a global variable. The mode could be changed by a
loadable bundle without the application code being aware of it.
Hence, code can be expecting to run in one mode and be invoked when it's
Further, it could be changed in one thread and mess up the processing in
a different thread which happens to be executing at that time.

It's a non-issue, switching is there for testing purposes and real programs don't do it. Once we are out of testing, programmatic switching of modes can be removed (unless people want to keep it for some reason).

* review and recommendations for NSString & NSFileManager

I've argued that we don't need Local<->OpenStep conversion generally
We also don't need the special ~drive and address@hidden notations. For
starters, though I find it bizarre I have come across accounts with user
name eg 'a'. Anyway, we don't need the ~ encodings.

I'm working on demonstration code to remove these by defining clear path
handling semantics which are appropriate for *nix and for win32 without
confusing either.

I've already done that ...
That's why I wanted to know what you were doing :-)

* string optimisations for the Win32 API where buffers are used
extensively. Initial testing suggests significant savings are possible but I want to investigate further.

Sounds good.

reply via email to

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