On Thu, 2004-10-28 at 22:31 +0100, J. Ali Harlow wrote: > Guys (and especially Tor), > > I was trying to use the new encoding scheme for 2.6 today when I was > writing a simple application which is passed filenames on the command line > (I need this under win32 so that I can support explorer's "Open with..." > system without using COM). The problem is that in this case argv[i] is in > filename encoding under Unix and locale encoding under win32 so the > application has to call either g_filename_to_utf8 (Unix) or > g_locale_to_utf8 (win32) which is pretty messy. I've been trying to think > of how we could improve this but I haven't thought of anything better than > adding yet another function and another encoding domain. Any better ideas? Well, on Unix the encoding of a filename argument depends on intent; if it's a filename, it's filename encoded. If it's a human readable string, it's locale encoded. So, it's not trivial there either. GOption already has the necessary logic to handle this. What if we added a magic option name, say #define G_OPTION_REMAINING ((gchar *)1) (or #define G_OPTION_REMAINING "__g_remaining" to be less magic and less efficient) Then you could use any of the types G_OPTION_ARG_FILENAME, G_OPTION_ARG_FILENAME_ARRAY, G_OPTION_ARG_STRING, STRING_ARRAY and it would magically do the right thing. If you use mixed filenames and human readable names, you'd be out of luck, but how common is that? Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part