[PATCH] Reformat statistics tab in MainTab tab widget

[Amit Chaudhuri]

I have found that with Qt I sometimes want to use the *.ui and Qt designer
approach to making a widget and at other times I prefer to hand code them,
avoiding designer completely.  I may well change my mind about what is more
appropriate about widget X during a project.

So if we can work out the Makefile logic to allow both approaches it would
be nice - from my point of view. I think this boils down to getting the
build system to do what qmake does when using the *.ui approach or using
the tr() marking if hand coding.  So, I suspect Thiago's earlier advice may
have sorted this for us.  But I could be wrong..




On Mon, May 6, 2013 at 3:41 PM, Lubomir I. Ivanov <neolit123 at gmail.com>wrote:

> On 6 May 2013 16:56, Dirk Hohndel <dirk at hohndel.org> wrote:
> > So we need to make sure that the strings from those .ui files get fed
> > into the translation.
> >
> > The marking with _("") or N_("") and even with tr("") have one
> > interesting side effect - the strings get picked up by our tooling and
> > then sent to Transifex for translation.
> >
> > At this point we still need to add magic to the Makefile to ensure that
> > the strings from the .ui file are picked up as well.
> >
>
> i would leave the .ui files with blank strings and assign values on
> runtime, by referencing labels and other objects i.e. in source files,
> how it was with the dynamically created UI in GTK. but in any way,
> text labels may have to be modified on runtime, if showing dynamic
> error messages to users.
>
>
> http://www.gnu.org/software/gettext/manual/html_node/xgettext-Invocation.html
> has a -L option but i don't see the Qt format supported, so this
> requires more Makefile magic, indeed.
> but i'm a bit confused here. even if strings are obtained from .ui and
> packed in .mo files, how would gettext know where to translate without
> the translation "guide" on runtime (e.g. gettext(), _(), _N()) and
> without referencing an object like:
>
> theLabel->text(_("the text"));
>
> which leads back to (or at least suggests to me) managing the strings
> from .cpp files only by referencing, which might be a problem on it's
> own if objects change names often...
>
> lubomir
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130506/95c36aa7/attachment.html>