Re: g_filename_to_utf8 limitations on Win32

[Matthias Clasen <mclasen redhat com>]

On Thu, 2004-10-28 at 17:50, Owen Taylor wrote:
> 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. 
> 

Nice idea. I did it like that. It turned out that "" is an ideal
candidate for a magic string, since -- is special-cased anyway. I've
made it so that the magic string is only recognized in the main group,
I think that makes sense.

Matthias