[PATCH] Reformat statistics tab in MainTab tab widget

Amit Chaudhuri amit.k.chaudhuri at gmail.com
Mon May 6 23:24:46 PDT 2013


Maybe not always better but some times useful....

If you look at the output in a ui_*.h file it is a bunch of C++.  The other
technique is to just write that stuff direct.  It assumes you are fairly
fluent in Qt-dialog-speak but can conveniently give some additional control
and/or allow you to use coding techniques which designer can't use.

Example might be the info page of the tab widget.  Instead of individually
specifying the various calls to clear and maybe missing one...

ui->sacText->setText(QString());

..it is possible to write a loop which runs through all widgets on the page
and calls setText() if the widget is a QLabel and the object name contains
a certain phrase.






On Mon, May 6, 2013 at 11:45 PM, Tomaz Canabrava <tcanabrava at kde.org> wrote:

> hm... what are the approaches that you think are better without the
> designer?
>
>
> 2013/5/6 Amit Chaudhuri <amit.k.chaudhuri at gmail.com>
>
>> 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/20130507/b54ee697/attachment-0001.html>


More information about the subsurface mailing list