|
That's correct. I, accidentally asked the same question on the gtk mailing lists and someone was worried about UTF8 and std::string. To tell you the truth, I am not able to understand what the problem might be. But for the time being I target only linux. @everyone thank you for your help. If I have time I may file documentation bug. > Date: Sat, 2 May 2009 22:42:57 +0100 > From: chris cvine freeserve co uk > To: hub figuiere net > CC: sledgehammer_999 hotmail com; gtkmm-list gnome org > Subject: Re: Where is Glib::strfreev()? > > On Sat, 02 May 2009 12:34:25 -0400 > Hubert Figuiere <hub figuiere net> wrote: > > > > Sidenote: I use std::vector<Glib::ustring> as container. Is that > > > correct, or should I use std::string? > > > > The question is: does it compile? If it does then you already have > > the answer. > > I don't think that is his point. There is a longstanding bug in > glibmm, which cannot be fixed without breaking API, concerning functions > which return file names. These generally return a Glib::ustring object > or a container of Glib::ustring objects, even though the filename > codeset may not be utf-8 (that depends on the G_BROKEN_FILENAMES and > G_FILENAME_ENCODING environmental variables). > > If that affects uris returned by Gtk::SelectionData::get_uris(), and I > do not know if it does or it doesn't, it will be necessary to transfer > the uris to std::string objects before calling anything other than > const methods on the strings concerned. (It is OK just to read them.) > I think the OP's question is whether the codeset returned by > Gtk::SelectionData::get_uris() is guaranteed to be utf-8. > > Chris Σύρετε φωτογραφίες στο παράθυρο του Messenger. Δείτε πώς. Κάντε κλικ εδώ! |