Using KCompressionDevice with QSaveFile

[Dominik Haumann]

Hi David,

On Wednesday 04 December 2013 14:42:19 David Faure wrote:
> On Monday 02 December 2013 22:31:43 Dominik Haumann wrote:
> > Hi,
> > 
> > porting KSaveFile to QSaveFile, I stumbled into the following:
> > 
> > // This method has been made private so that it cannot be called,
> > // in order to prevent mistakes.
> > void QSaveFile::close()
> > {
> > 
> >     qFatal("QSaveFile::close called");
> > 
> > }
> > 
> > In Kate, we use a QSaveFile saveFile(...); and then use
> > 
> >   KCompressionDevice compDevice(&saveFile, ...);
> > 
> > to write compressed data through compDevice into saveFile.
> > 
> > However, KCompressionDevice at some point always seems to call close(),
> > which hits the qFatal().
> > 
> > Should I derive from QSaveFile and overwrite close() to call commit() ?
> > Am I missing something here?
> 
> I just added a unittest in kdelibs-frameworks's kfiltertest, and it works
> for me.
> Can you check 1) that it works for you, 2) what your code does differently
> from the unittest ? And then change the unittest to show the problem, so I
> can look into it.
> 
> Thanks!

First of all, thanks a lot for adding the unit test and looking into this.
It turns out that it also runs correctly for me (not really a surprise, right?) ;)

However, here it comes: Changing 
-        KCompressionDevice device(&file, false, KCompressionDevice::GZip);
+        KCompressionDevice device(&file, false, KCompressionDevice::None);
will run into this issue.

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.

First, we get the warning that the file is already open.
Then, the assert.

It seems that the behavior for "None" is different. Interestingly, KSaveFile also
behaved like this (KFilterDev did not change after all I guess). 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.

Greetings,
Dominik