After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591302 - [Windows] Accents like àçèé^`¨ in file path (or filename)
[Windows] Accents like àçèé^`¨ in file path (or filename)
Status: RESOLVED DUPLICATE of bug 570592
Product: dia
Classification: Other
Component: general
0.97-pre3
Other Windows
: Normal trivial
: ---
Assigned To: Dia maintainers
Dia maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-10 08:31 UTC by Florian
Modified: 2010-01-24 17:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Florian 2009-08-10 08:31:30 UTC
[Windows] (tested Windows 2k/XP) - If I'm using an accent like àçèé^`¨ in file path (and/or filename), it disables opening .dia with 'diaw --integrated''.

In fact, when I double-click on a .dia with an accent in file path, nothing happens (!), the only way to open the file, is to open dia and then, open the file (!).
Comment 1 Hans Breuer 2009-11-07 17:46:48 UTC
This is a flaw in dia-win-remote.c, it could be overcome by using the WCHAR version of the win32 API.
Comment 2 Steffen Macke 2009-11-09 21:26:58 UTC
I'm working on this API switch in dia-win-remote now.

However, I'm not sure how to handle this problem: (Output from the cmd.exe commandline)

>dia.exe e:\tmp\löäöä.dia
[Invalid UTF-8] \xbbe:\tmp\l\xf6\xe4\xf6\xe4.dia\xab nicht gefunden

Should Dia explicitly test commandline parameters for wchars? Or should dia-win-remote convert the commandline parameters to UTF-8?
Comment 3 Hans Breuer 2009-11-09 21:43:02 UTC
g_print and most other GLib APIs expect utf-8, the windows API to use is wchar, e.g. GetCommandLineW(). I think there is almost no GLib usage required in dia-win-remote. But if there is use g_utf16_to_utf8() before passing wide-char filename.
Comment 4 Hans Breuer 2010-01-24 17:43:04 UTC
All the issue here should be resolved by the patch set just applied for bug #570592

*** This bug has been marked as a duplicate of bug 570592 ***