Review Request 129170: Add KArchive::errorString() method to provide more details on KArchive errors

[Romário Rios]

> On Oct. 15, 2016, 4:05 p.m., David Faure wrote:
> > src/k7zip.cpp, line 2343
> > <https://git.reviewboard.kde.org/r/129170/diff/3/?file=482230#file482230line2343>
> >
> >     QObject::tr() is bad practice in Qt code (the context class name is then "QObject" instead of e.g. K7Zip).
> >     
> >     However I assume that our ts -> po tools don't really care about the context classname (since po doesn't have that), so maybe it doesn't matter. It still shows bad practice for people actually using lupdate.
> >     
> >     (BTW the solution for the fact that this isn't a QObject-derived class is to add Q_DECLARE_TR_FUNCTIONS to the class definition)
> 
> Friedrich W. H. Kossebau wrote:
>     The ts -> po tools make extra efforts to indeed care about the context :) Cmp. https://websvn.kde.org/trunk/l10n-kf5/templates/messages/frameworks/kcoreaddons5_qt.pot?view=markup and see the extra tags `#, qt-format` and `msgctxt "KAboutLicense|"`, which lconvert then uses for creating qm files with the context as wanted.
>     
>     So best no QObject::tr(), but using Q_DECLARE_TR_FUNCTIONS when needed, indeed. Especially for apps linking to lots of libs that use QTranslator-based translations, having different context is important to avoid clashes for common terms.

Thanks for the info, I wasn't aware of `Q_DECLARE_TR_FUNCTIONS`.


> On Oct. 15, 2016, 4:05 p.m., David Faure wrote:
> > src/k7zip.cpp, line 2874
> > <https://git.reviewboard.kde.org/r/129170/diff/3/?file=482230#file482230line2874>
> >
> >     As previously discussed, I think this should (also) be a qWarning.
> >     
> >     API misuse => qWarning.
> >     
> >     Reasoning: if a bad programmer misuses the API *and* doesn't check errorString, he/she won't find out.
> >     
> >     And the tr() string might need adjustment, this is shown the user, but the "you" in the string isn't the user. I'd say
> >     
> >     setErrorString(tr("Application error: 7-Zip file not open before writing to it, please file a bug report at https://bugs.kde.org"))

Why was the `qWarning` commented out in the first place, though? Should we bring it back?
> And the tr() string might need adjustment, this is shown the user, but the "you" in the string isn't the user.

Makes sense.
> file a bug report at https://bugs.kde.org

I think this implies the application using the library is a KDE App, which isn't necessarily the case.


- Romário


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129170/#review100017
-----------------------------------------------------------


On Oct. 15, 2016, 3:08 a.m., Romário Rios wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129170/
> -----------------------------------------------------------
> 
> (Updated Oct. 15, 2016, 3:08 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: karchive
> 
> 
> Description
> -------
> 
> This method is similar to `QIODevice::errorString()`. I added a public `errorString()` method and a protected `setErrorString()` method, to allow `KArchive`'s subclasses to implement their own error messages. I also implemented most error messages from most subclasses.
> 
> 
> Diffs
> -----
> 
>   autotests/karchivetest.cpp d0fbf41 
>   src/k7zip.cpp 692b1db 
>   src/kar.cpp 7204fb1 
>   src/karchive.h b528a4a 
>   src/karchive.cpp a1a160a 
>   src/karchive_p.h 256620d 
>   src/krcc.cpp 1947dd6 
>   src/ktar.cpp f70b155 
>   src/kzip.cpp 94d4276 
> 
> Diff: https://git.reviewboard.kde.org/r/129170/diff/
> 
> 
> Testing
> -------
> 
> I added `QVERIFY` calls after all errors in `karchivetests.cpp`. Perhaps we'll need more tests, but I'm not sure how to make an archive to fail in some specific way aside from the very basics ("file not found", etc.).
> 
> 
> Thanks,
> 
> Romário Rios
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161015/fda171fb/attachment-0001.html>