Re: Glib::ustring tradeoffs?

[Matthias Kaeppler <matthias finitestate org>]

Chris Vine wrote:
> ...  As in your example you are hardwiring the text into the 
> source code, then the best thing is not to convert the text, but to write the 
> hardwired string in UTF-8 in the first place.  (As it happens, "BUTTON" is 
> valid ASCII and therefore valid UTF-8.)

What does that mean? How do I "write in UTF-8"? ^^

And since the string "text" is both valid ASCII and UTF-8, why do I have 
to call locale_from_utf8() to convert it to an std::string:

glib::ustring str1 = "text"; // is both valid ASCII and UTF8
std::string str2 = str1; // doesn't work
str2 = glib::locale_from_utf8(str1); // works

It would have worked the other way around though, without a conversion 
function. I don't see why. What exactly is happening in these conversion 
functions?

> Normally if you are hardwiring text into your source code, such as the text 
> for a label or button, you would enable translations from different languages 
> by using gettext() and intltools.  You can ensure that gettext() provides the 
> translated text in valid UTF-8 format by calling 
> bind_textdomain_codeset([prog_name], "UTF-8") after the call to 
> bindtextdomain().  The text can then be put directly into a GTK+/gtkmm 
> widget.

Yes, in the long run I will probably have to use GNU gettext anyway, but 
localization wasn't a priority for me (in this early stage of 
development) so all I am doing for now is trying to keep the GUI text 
all in one place (as #defines in a header file) and use Glib::ustring as 
much as possible, in order to make incorporating gettext one day as easy 
as possible.

By the way: I noticed that operator[] only works in one way for 
Glib::ustring. How come I can only read characters with it, but not 
write them?

Example:

Glib::ustring str = "text";
assert (text[0] == 't'); // works
text[0] = 'n'; // fails

Regards,
Matthias