GOption migration patch
Hello
Can anyone review the patch provided here: https://bugs.launchpad.net/inkscape/+bug/195220 It moves the commandline option parsing from popt to GOption and shortens main.cpp a fair bit, but I'm not sure how does Inkscape open files - does it (1) use UTF-8 filenames or (2) filenames in the system encoding? This patch will be ok if 2 is the case, and I believe 2 is the standard practice with Glib.
Regards, Krzysztof (Chris) Kosiński
On Mar 13, 2008, at 3:19 PM, Krzysztof Kosiński wrote:
Hello
Can anyone review the patch provided here: https://bugs.launchpad.net/inkscape/+bug/195220 It moves the commandline option parsing from popt to GOption and shortens main.cpp a fair bit, but I'm not sure how does Inkscape open files
- does it
(1) use UTF-8 filenames or (2) filenames in the system encoding? This patch will be ok if 2 is the case, and I believe 2 is the standard practice with Glib.
That's actually a bit tricky. It should actually be using neither of those encodings. Instead it should be using the third type of encoding which is filename encoding (GTK apps have to juggle system, internal/UTF-8 *and* filesystem)
The standard with GLib has been that it uses filesystem encoding. Sometimes filesystem encoding is the same as system encoding (in which case you'll notice no difference). Other times filesystem encoding is different.
What makes it even trickier is that the filesystem encoding can be the original one used waaaaaaaay back when the filesystem was installed. For example I've seen Japanese systems that have a Linux distro installed that uses UTF-8 as the system and filesystem encodings *but* on a specific box use ISO-2022-JP for the filesystem instead since it was an older system that had been upgraded.
I once wondered why we used Popt instead of Getopt...
until i noticed that Popt has superior I18N error messages.
is there a good reason to change?
bob
Jon A. Cruz wrote:
On Mar 13, 2008, at 3:19 PM, Krzysztof Kosiński wrote:
Hello
Can anyone review the patch provided here: https://bugs.launchpad.net/inkscape/+bug/195220 It moves the commandline option parsing from popt to GOption and shortens main.cpp a fair bit, but I'm not sure how does Inkscape open files
- does it
(1) use UTF-8 filenames or (2) filenames in the system encoding? This patch will be ok if 2 is the case, and I believe 2 is the standard practice with Glib.
That's actually a bit tricky. It should actually be using neither of those encodings. Instead it should be using the third type of encoding which is filename encoding (GTK apps have to juggle system, internal/UTF-8 *and* filesystem)
The standard with GLib has been that it uses filesystem encoding. Sometimes filesystem encoding is the same as system encoding (in which case you'll notice no difference). Other times filesystem encoding is different.
What makes it even trickier is that the filesystem encoding can be the original one used waaaaaaaay back when the filesystem was installed. For example I've seen Japanese systems that have a Linux distro installed that uses UTF-8 as the system and filesystem encodings *but* on a specific box use ISO-2022-JP for the filesystem instead since it was an older system that had been upgraded.
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Jon A. Cruz wrote:
That's actually a bit tricky. It should actually be using neither of those encodings. Instead it should be using the third type of encoding which is filename encoding (GTK apps have to juggle system, internal/UTF-8 *and* filesystem)
The standard with GLib has been that it uses filesystem encoding. Sometimes filesystem encoding is the same as system encoding (in which case you'll notice no difference). Other times filesystem encoding is different.
Thanks for the clarification. I already knew about the filename encoding in Glib, but I made a mental shortcut and assumed that filesystem encoding = system encoding. This patch requests filenames in the filename encoding.
Bob Jamison-2 wrote:
I once wondered why we used Popt instead of Getopt... until i noticed that Popt has superior I18N error messages. is there a good reason to change?
bob
1. GOption is not getopt. GOption has built-in I18N support and handles the conversion to console encoding automatically, whereas popt doesn't (there was a hack to change the gettext encoding before invoking popt, which I have removed). getopt is pretty bare-bones. 2. GOption is part of Glib, which Inkscape depends on anyway, while popt is an external library. So this would rip out a dependency. 3. GOption has option grouping, better command line help, can handle option groups supplied by GTK (which we would otherwise have to reimplement) and is in general much cleaner to use than popt. The only regression is that the help messages are not nicely aligned to 80 characters (there are also some potential problems with Windows, but they will be easy to fix if they appear). On the other hand, the current behaviour is better when piping the help output to some file to read it later.
Regards, Krzysztof Kosiński
participants (3)
-
Bob Jamison -
Jon A. Cruz -
Krzysztof Kosiński