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 usa 8 bits por caractere, mas essa quantidade não é suficiente para codificar idiomas como árabe, chinês e japonês. Embora as codificações para esses idiomas agora estejam especificadas pelo Consórcio Unicode, as linguagens C e C++ ainda não oferecem suporte a Unicode de forma padronizada. GTK+ e GNOME escolheram implementar Unicode usando o UTF-8, e o Glib::ustring é um wrap justamente para isso. Ele fornece praticamente a mesma interface que std::string, juntamente com conversões automáticas de e para 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.