[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Patch for Unicode support on Win32 in GNUstep base (take 2)
From: |
Roland Schwingel |
Subject: |
Patch for Unicode support on Win32 in GNUstep base (take 2) |
Date: |
Tue, 07 Dec 2004 16:27:25 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 |
Hi...
In August I already proposed a patch here to allow GNUstep on Windows
to properly handle filenames containing unicode characters
(see:
http://lists.gnu.org/archive/html/discuss-gnustep/2004-08/msg00022.html).
As of the fact that -[NSFileManager fileSystemRepresentationWithPath:]
returns (const char *) we introduced a new method called
-[NSFileManager wfileSystemRepresentationWithPath:] in these days, to allow
unicode safe representations of a path to not conflict with given the
OpenStep API.
Not everyone was feeling happy with this new method because the developer
must now decide what to call. After a discussion with Richard and Adam we
changed the patch now. Richards idea was to introduce an api that works
with NSStrings instead of CStrings, so it can work on all platforms
transparently and the regular developer does not need to worry about
encodings etc.
We added the 2 new suggested methods to NSFileManager:
-localFromOpenStepPath: and -openStepPathFromLocal:
to handle conversion between strings containing native path format
and separators etc, to the standard unix-style paths used internally
by the GNUstep libraries.
This also helped to simplify already present code in
eg. GSDirectoryEnumerator.
We adapted all code in gnustep base to meet the changes and tested the
changes
intensively, without noticing any problems. So here is the patch to
allow gnustep
applications to work with unicode pathes on windows.
Hope you can apply this patch,
Roland
GNUstep_Win32UnicodeSupportPatch.tar.gz
Description: GNU Zip compressed data
- Patch for Unicode support on Win32 in GNUstep base (take 2),
Roland Schwingel <=