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