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