[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