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
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
