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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
