Re: g_filename_to_utf8 limitations on Win32

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, 
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?


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]