Review Request: Use QT_USE_FAST_CONCATENATION and QT_USE_FAST_OPERATOR_PLUS for performance.

[Rick W. Chen]

> On 2010-09-29 12:18:00, Rick W. Chen wrote:
> > src/browsers/collectionbrowser/CollectionWidget.cpp, lines 176-178
> > <http://git.reviewboard.kde.org/r/100008/diff/1/?file=463#file463line176>
> >
> >     The "added" i18n string is taken from CollectionTreeItemModelBase::addFilters(). They need to be the same so that the filtering will work. So it might break if the translation uses different "added" for the two places.
> >     
> >     Similarly, the 'd', 'w', 'm' etc. are also hardcoded in CollectionTreeItemModelBase::semanticDateTimeParser(). So the same thing applies here.
> >     
> >     Ideally we should make all of them translatable with context while ensuring they are consistent.
> 
> Mark Kretschmann wrote:
>     Could you please elaborate? What concrete solution do you suggest, in code?
> 
> Ian Monroe wrote:
>     Well for this we just need to keep the "1d" "1w" stuff out of i18n. I'm not really sure why the old version doesn't compile so dunno a solution.
>     
>     Maybe we should use i18n args? doesn't something like
>     
>     i18n("added %1", ":<1d") work? I forget the exact syntax. This has the advantage of allow languages to move the verb relative to the less then sign.
>     
>     would that break filtering Rick?

What's happening is this:

In the filtering code we compare "added" and i18n("added") for the token. In the
above code we have a combo box storing 3 presets. When the user selects "Added
Today", the string "added:<1d" will be inserted in the line edit and filtering
is triggered.

If we change the i18n("added") stored in the combobox, the translator will see
separate strings to translate. If "added" is translated differently for the two
cases then filtering will not work.

Right now the translators might ignore this completely anyway since
i18n("added") is just confusing. So adding some context should help, e.g.
i18nc("Token for filtering tracks added since a certain time", "added"). If we
do that, the same context will need to be added to the same token in the
filtering code to make them the same localization string. We should do the same
for all other tokens as well.

For the filter string ("<1d" etc.), since they are not made translatable these
should be kept out of i18n, as Ian suggested.

With something like i18n("added:%1", "<1d"), the issue remains where there will
be separate strings to translate. It will break if the translations are
different.

I don't think this is a problem (concatenating strings as it is now), since
these are only done once and only a handful of strings. Furthermore we have the
EditFilterDialog which presumably the users will first find out about this
feature. To help with translations I suggest adding contexts to all those
tokens. A minor speedup here would be to use QLatin1String instead of QString
for the ":<1d" etc.


- Rick W.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100008/#review38
-----------------------------------------------------------


On 2010-09-30 16:12:51, Mark Kretschmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100008/
> -----------------------------------------------------------
> 
> (Updated 2010-09-30 16:12:51)
> 
> 
> Review request for amarok.
> 
> 
> Summary
> -------
> 
>     Use QT_USE_FAST_CONCATENATION and QT_USE_FAST_OPERATOR_PLUS for performance.
>     
>     See http://doc.trolltech.com/4.6/qstring.html#more-efficient-string-construction.
>     
>     I had to clean up lots of incorrect string concatenations. Please check for
>     correctness.
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt abdcee8 
>   src/aboutdialog/OcsPersonItem.cpp 6685aa1 
>   src/browsers/collectionbrowser/CollectionWidget.cpp 196837c 
>   src/browsers/playlistbrowser/DynamicModel.cpp af7742d 
>   src/context/applets/similarartists/SimilarArtistsApplet.cpp e1e5d59 
>   src/context/applets/upcomingevents/UpcomingEventsApplet.cpp 7233785 
>   src/core-impl/collections/audiocd/AudioCdCollection.cpp a10976b 
>   src/core-impl/collections/daap/DaapCollection.cpp 06e97b2 
>   src/core-impl/collections/sqlcollection/SqlCollectionLocation.cpp e9411e6 
>   src/core-impl/collections/sqlcollection/mysqlecollection/MySqlEmbeddedStorage.cpp b3b40bc 
>   src/core/support/Debug.h 62766c4 
>   src/dynamic/Bias.cpp dec2db2 
>   src/dynamic/BiasSolver.cpp 0be91da 
>   src/dynamic/biases/EchoNest.cpp 2d0038a 
>   src/scriptengine/AmarokCollectionScript.cpp da87d33 
>   src/services/lastfm/CMakeLists.txt 7f17ff7 
>   src/services/lastfm/LastFmService.cpp 3b291fe 
>   src/services/lastfm/LastFmServiceSettings.cpp 6517fea 
>   src/services/lastfm/biases/LastFmBias.cpp 6f3286c 
>   src/services/lastfm/biases/WeeklyTopBias.cpp 98f9257 
> 
> Diff: http://git.reviewboard.kde.org/r/100008/diff
> 
> 
> Testing
> -------
> 
> This still fails to compile because of one error in libLastFM. Who is up for fixing the lib? :)
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20101001/c3c5d42f/attachment.htm