2015-11-21 21:02 GMT-03:00 David Faure <fa...@kde.org>: > > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125974/ > > On November 7th, 2015, 9:25 a.m. UTC, David Faure wrote: > > BTW why create a KTar on top of a KCompressionDevice? KTar is able to handle > compression automatically all by itself... and that's exactly the case where > it will use a tempfile for the uncompressed data, making seeking work. This > patch is unnecessary if you use KTar the intended way: if the filename > doesn't end with .gz or .bz2, specify the mimetype explicitly in the KTar > constructor. > > On November 21st, 2015, 7:11 p.m. UTC, Romário Rios wrote: > > KCompressionDevice is supposed to be used when you want to extract data from > a QIODevice directly instead of a file -- KTar only handles compression > automatically if you pass it a filename. ATM, KCompressionDevice doesn't seem > to work properly with many QIODevices -- not even with QBuffer. > > KCompressionDevice should certainly work on top of a QBuffer. I just > committed a unittest that shows it working (but of course there might be a > bug in some other way to use it, feel free to show me in which case it > doesn't work).
Please take a look at my patch from the #125941 review request: https://git.reviewboard.kde.org/r/125941/diff/2#2 It seems none of the test*BufferedNetworkReplyDevice tests work. > > Also, it's not true that KTar only handles compression if given a filename. > You can also pass it a mimetype like application/x-gzip and then it will use > compression. What I meant was that, besides the QIODevice * constructor, KTar only has a constructor taking a filename and (optionally) a mimetype. > > > - David > > > On November 6th, 2015, 2:52 a.m. UTC, Romário Rios wrote: > > Review request for KDE Frameworks and Aleix Pol Gonzalez. > By Romário Rios. > > Updated Nov. 6, 2015, 2:52 a.m. > > Repository: karchive > > Description > > Up until now, since at least 5.12, decompressing some data coming directly > from a QIODevice by using KCompressionDevice because this is a sequential > device, and KTar and KArchive used to use QIODevice::seek and pos and some > places, which made the decompression fail. This patch makes KTar > sequential-friendly by replacing the calls to seek and pos with read and a > simple counter, respectively. > > Testing > > Makes the tests from review #125941 pass > > Diffs > > src/karchive.cpp (0ece37c) > src/ktar.cpp (824395e) > > View Diff -- Luiz Romário Santana Rios _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
