[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.
Hmm...
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
different.
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.
- Apple changed documentation for -[NSString stringByExpandingTildeInPath], Markus Hitter, 2005/05/06
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], Philippe C.D. Robert, 2005/05/07
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], Sheldon Gill, 2005/05/07
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], Richard Frith-Macdonald, 2005/05/09
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], Sheldon Gill, 2005/05/09
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath],
Richard Frith-Macdonald <=
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], David Ayers, 2005/05/10
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], Sheldon Gill, 2005/05/10
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], Richard Frith-Macdonald, 2005/05/10
- Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath], Adam Fedor, 2005/05/10