Bugzilla – Full Text Bug Listing
| Summary: | DBCS: DBCS named file drag&drop failure on GTK | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Masayuki Fuse <fuse> | ||||
| Component: | SWT | Assignee: | Veronika Irvine <veronika_irvine> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipse.felipe, snorthov, veronika_irvine | ||||
| Version: | 2.1.1 | ||||||
| Target Milestone: | 3.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux-GTK | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Masayuki Fuse
Created attachment 5810 [details]
DBCS named file encoded by EUC-JP
VI to investigate To test this I drag&drop from Nautilus to the DragAndDropExample (swt internal). I'm not sure but I guess is: in DropTarget.drag_data_received() it calls FileTransfer.nativeToJava() which attempts to converts the data (byte array) to a string using Converter.mbcsToWcs which uses g_utf8_to_utf16. But in this case you don't want to convert from utf8 to utf16 but from eucpj to utf16. Some questions: The name of the file is encoded in eucjp but the content in utf8 ? The name of the file is build[NIHONGO].xml where [NIHONGO] is the glyph produced by typing nihongo and converting to kanji ? Answer to questions: >>The name of the file is encoded in eucjp but the content in utf8 ? Yes, that's right for the attachment at #1. But even if the content is in eucjp, the problem occurs. Here is another scenario, drag&drop from the workbench to Nautilus won't be copied the file if its name is in DBCS. >>The name of the file is build[NIHONGO].xml where [NIHONGO] is the glyph produced by typing nihongo and converting to kanji ? Yes, that's right. The SWT team will look at this for 2.1.2 Steve - can you please change the milestone to 2.1.2 There is another problem here. According with RFC2396, in a URI any character that is not US-ASCII has to be represented as a % escape sequence (% hex hex). SWT does not do this. Anyway I don't think SWT should get in the business of parsing URI. Our options are: Option 1: use g_filename_to_uri() It which encodes the URI in UTF-8 and therefore will not fix this problem. But it seems the UTF-8 is the right encoding for pure GTK apps. Test: run testgtk (open the file selection dialog), eclipse (import build[nihongo].xml into a project, run nautilus. You can drag&drop build[nihongo].xml from eclipse into testgtk but it doesn't work if you try to drag&drop from nautiles to testgtk. 2. Option 2: gnome_vfs_get_uri_from_local_path () Encodes the URI using the platform encoding, that is what gnome apps do. The FileTransfer class needs to be changed to use g_filename_to_uri()and g_filename_from_uri(). However, this is basically a rewrite of the FileTransfer class and I am not really comfortable in porting it back to 2.1.2. Further, it does not fix the interaction with Nautilus. The text/uri-list supplied by Nautilus results in the error "The URI file:///.... contains invalidly escaped characters". The file can be dragged within Nautilus, however, in addition to text/uri-list Nautilus uses x-special/gnome-icon-list type. I believe Nautilus is succeeding because the implementation of x- special/gnome-icon-list supports double byte characters better. If the application really needs to interact with Nautilus or any other Gnome app it always can implement its own Transfer to do the task. I'm pretty sure there are Java libraries that provide URI manipulation (of course, java application would not need to use gnome-vfs) that can be used combined with ByteArrayTransfer to pass the data down as a byte array. I agree with VI decision. Note: if by coincidence, the current locale is ja_JP.UTF-8, Eclipse and Nautilus would exchange data via D&D correctly. Downgrading to P3. I've confirmed that this scenario worked fine in Eclipse 3.1 M6 on RHEL4 WS ja_JP.UTF-8 locale. I agree to close this pr. Thank you for verifying. Closing. |