John,
It may be done poorly. But the idea is to switch the encoding in the image by providing the right fileNameConverter.
I'm not sure what you mean by "in image encoding assumes latin-1". If the file browser doesn't show the right file name, the right fix is to change the fileNameConverter, not changing the VM.
-- Yoshiki
At Wed, 29 Mar 2006 21:35:47 -0800, John M McIntosh wrote:
Ah, poorly.
From what I've seen the in image encoding assumes latin-1. It gets macroman from the VM and mangles, demangles that ok, however displays the characters then wrong in the file browser. If you switch the VM to use latin-1 then characters are displayed correctly, however it is possible to create file names that contains characters that UTF-8 allows but has not latin-1 mapping, thus the internal VM mapping from that character to latin-1 fails.
Keeping the VM in UTF-8 seems to work, of course FilePath mangles that as latin-1 and the names are not displayed correctly.
On 29-Mar-06, at 6:42 PM, Yoshiki Ohshima wrote:
Hello,
Well, my point is that if we expose that primitive to the image, we will never have the need to do it from a plugin because you can always pass a valid file name into it. It's really strange to me that the VM does translation for stuff which is (supposedly) handled in the image already. I could understand this if we would shoot for a file/ directory abstraction inside the image but the way it's right now we're hiding stuff from the image that the image supposedly is responsible for (platform file name handling) and that's Just Wrong (tm).
Since Squeak3.8, FilePath class is supposed to do the conversion. I wonder if how ioFilename:fromString:ofLength:resolveAliases: interacts with FilePath...
-- Yoshiki
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===