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