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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel