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.
That's actually quite well contained, really. There is more of my
NSPathUtilities bit and a few more Win32 support routines. {Strings
excepted}
I found the new Tiger dirs to be amusing. I had to drop my
GSCacheDirectory and GSDesktopDirectory keys...
IsExecutable and show/hide extensions are pretty trivial NSFileManager
based on that.
I've also a rev for NSTimeZone which fixes some Win32 strangeness,
cleans a little code and provides for more flexible packaging but I
thought this was a little outside of this discussion. Again, it needs
the Win32 support improvements.
So I was thinking it'd be a reasonably straight-forward commit but there
is the binary compatibility break we're heading to, which is the right
time to do this.
* 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).
In my view there should be one and only one mode. Well defined behaviour
that can be relied on.
The current behaviour of 'do the right thing' doesn't, in my view, do
the right thing and gives rise to some quite strange results on win32.
* 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 [EMAIL PROTECTED] 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 :-)
I thought you might have. That's why I issued the invitation to ask ;)
Does this use the current path handling mode semantics?
* 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.
Yes and people will be happy that things are faster. I'm not sure
they'll like delving into the code, though. I'm taking GStr here.
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
