[PATCH] Reformat statistics tab in MainTab tab widget

Tomaz Canabrava tcanabrava at kde.org
Tue May 7 06:57:52 PDT 2013


instead of calling ui->lineEdit->setText(QString()) or ->clear(), why don't
you just connect the 'clear' button with the 'clear' slot on line edits
directly from the ui?

Less code written == less chance for bugs.


2013/5/7 Amit Chaudhuri <amit.k.chaudhuri at gmail.com>

> 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/50ce3e80/attachment.html>


More information about the subsurface mailing list