Glib::ustring
Você talvez fique surpreso ao aprender que gtkmm não usa std::string em suas interfaces. Em vez disso, utiliza Glib::ustring, que é bem similar e não obstrusivo que você poderia fingir que cada Glib::ustring é uma std::string e ignorar o resto desta seção. Mas continue lendo se quiser usar idiomas que não seja o inglês no seu aplicativo.
std::string uses 8 bit per character, but 8 bits aren't enough to encode languages such as Arabic, Chinese, and Japanese. Although the encodings for these languages have now been specified by the Unicode Consortium, the C and C++ languages do not yet provide any standardised Unicode support. GTK+ and GNOME chose to implement Unicode using UTF-8, and that's what is wrapped by Glib::ustring. It provides almost exactly the same interface as std::string, along with automatic conversions to and from std::string.
Um dos benefícios do UTF-8 é que você não precisa usá-lo a menos que queira, então não precisa mexer no seu código todo de uma vez. std::string funcionará também com textos ASCII 7 bits. Porém, quando você tentar fazer a localização do seu aplicativo para idiomas como chinês, por exemplo, você comerçará a ver uns erros estranhos, e possivelmente uns travamentos. Então, tudo que você precisa fazer é começar a usar Glib::ustring no lugar.
Note que UTF-8 não é compatível com codificações de 8 bits como ISO-8859-1. Por exemplo, os tremas alemães (umlaut) não estão na faixa ASCII e precisam de mais que 1 byte na codificação UTF-8. Se seu código contém textos constantes em 8 bits, você tem que convertê-los para UTF-8 (exemplo: o cumprimento da Bavária "Grüß Gott" seria "Gr\xC3\xBC\xC3\x9F Gott").
Você deveria evitar aritmética de ponteiros no estilo C e funções como strlen(). Em UTF-8, cada caractere pode precisar em algum lugar de 1 a 6 bytes, então não é possível assumir que o próximo byte é outro caractere. Glib::ustring se preocupa com esses detalhes para você para que possa usar métodos tais como Glib::ustring::substr() enquanto ainda raciocina em termos de caracteres em vez de bytes.
Ao contrário da solução Unicode UCS-2 do Windows, ele não exige quaisquer opções especiais do compilador para processar textos contantes, além de não gerar executáveis e biblioteca Unicode que sejam incompatíveis com os em ASCII.
Veja a seção Internacionalização para informações sobre como fornecer textos constantes em UTF-8.