[gtkmm] String composition API addition proposal

[Ole Laursen <olau hardworking dk>]

Hi!

I was thinking about what one might put in the i18n section of
"Programming with Gtkmm" when it occured to me that I couldn't find a
solution to the string composition problem in Gtkmm. Personally, I've
been using boost::lexical_cast<>:

  label.set_text("You have " + boost::lexical_cast<Glib::ustring>(letter_no)
                 + " letters in your inbox "
		 + boost::lexical_cast<Glib::ustring>(inbox_name) + ".")

But that has the problem of making the code somewhat hard to read and
also prone to forgetting a space somewhere. And it makes translation
of the strings very, very difficult.

A solution is to revert to C style printf - but encoding the type in
the string really sucks. Instead something like

  Composer("You have %1 letters in your inbox %2.") << letter_no << inbox_name;

would be nice; this also gives translators the freedom to swap the
position of the arguments. And that's what I've implemented. It turns
out using the << operator isn't too great since it prevents one from
the syntax

  cout << Composer("There were %1 errors.") << nerror;

Instead I noted that Qt is using a member function - then you get

  cout << Composer("There were %1 errors.").arg(nerror);

which looks ugly, but works. I've added a bunch (i.e. 10) of overloaded
compose functions which gives the neater

  cout << compose("There were %1 errors.", nerror);


Now, I'm proposing this is added to Glib since proper i18n without it
is a pain. The code can be found together with a Makefile and an
example program at

  http://sunsite.dk/olau/composer.tar.gz

I used an ostringstream for the formatting, so the class is very
simple, but also very flexible - for instance it supports
manipulators. Currently it's only tested with GCC 2.95.4 and 3.1
though. If adding it sounds worthwhile, I'll put it in a namespace,
write documentation etc., and put it in a bug on bugzilla.

There is a couple of design questions left, though. Perhaps it would
be better not to expose the Composer class at all and only rely on the
compose templates (I'd probably say yes if there is a private
namespace to put the class in)? And is 10 overloads enough or should
it be, say 20?


(PS: I'm probably without Internet access for the next 5 days or so, so
it may take some time before I can reply.)

-- 
Ole Laursen
http://sunsite.dk/olau/