Using KCompressionDevice with QSaveFile
David Faure
faure at kde.org
Tue Dec 10 22:31:33 UTC 2013
On Tuesday 10 December 2013 21:48:09 Dominik Haumann wrote:
> However, here it comes: Changing
> - KCompressionDevice device(&file, false, KCompressionDevice::GZip);
> + KCompressionDevice device(&file, false, KCompressionDevice::None);
> will run into this issue.
Great. A unittest patch to make it fail was exactly what I needed :)
> In that case, the unit test does the following:
> QWARN : KFilterTest::test_saveFile() QSaveFile::open: File
> (tier1/karchive/autotests/test_saveFile.gz) already open QFATAL :
> KFilterTest::test_saveFile() QSaveFile::close called
> FAIL! : KFilterTest::test_saveFile() Received a fatal error.
Yep.
> It seems that the behavior for "None" is different. Interestingly, KSaveFile
> also behaved like this (KFilterDev did not change after all I guess).
I'm surprised, because KCompressionDevice::None didn't exist before, it was
all new code in KF5. KFilterDev had very different code in KDE4, and no
support for "no compression" itself (deviceFromFile would simply return a
QFile instead of a KFilterDev, in that case).
Anyhow, it's fixed now, I rewrote the new "none" filter.
> And this case was caught with an "if" in Kate Part's file saving code.
> So yes, we can work around it again, just before.
> But: I do not really get why KCompressionDevice works completely different
> depending on the compression type. This makes using KCompressionDevice
> pretty ugly (im_h_o), since you have to manually check for None and take a
> different code path.
No need to convince me, I'm fully convinced :-)
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
More information about the Kde-frameworks-devel
mailing list