Using KCompressionDevice with QSaveFile

[Dominik Haumann]

On Tuesday 10 December 2013 23:31:33 David Faure wrote:
> 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 :)

Very good.

> > 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).

I did not look too closely into the KDE4 way, but we needed some kind of if 
there, too (according to Christoph). Well, nevermind ;)

> Anyhow, it's fixed now, I rewrote the new "none" filter.

Thanks! I will try on the weekend.

> > 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 :-)

;)

Best,
Dominik