2012/10/1 Mario Bensi <mbe...@ipsquad.net> > > I will use it of course, maintaining code already available in a larger > > codebase is not an option I would totally avoid it, although I hope it > will > > go in Qt 5.1+ because otherwise I will have to make my own github repo > > with a copy of it. > > > > What's you plan for pushing more kdelibs stuff in Qt 5.x guys? > > > > Anyway I looked at the code from the frameworks branch, the > > tier1/karchive directory doesn't seem to load plugins at runtime > > the way I do. It seems it still has classes such as KTar in the > > library itself, this means that: > > * each time you want to add support for another archive format you > > need to release another version of the library and third parties won't > > be able to write their plugins (the opposite of, for example, the > > modular design for image support in Qt) > > Yes you right in this point. It may be a good idea to add this behaviour in > karchive for framework. Do you want work on this change ? >
Yes, it's "just" a matter of finding some time but I will definitely do it. I have got kdelibs frameworks branch checked out, and I'm going to build it, the next weeks I will try to make room to my schedule and send a patch. > > * applications need to know the format in advance, my implementation > > instead had a public generic API that lets you open a file then it > > detects the mime type and load the appropriate plugin for you. > > For this point you can use KFilterDev::KFilterDev(const QString& fileName) > to > use the KCompressionDevice or use findCompressionByFileName(fileName) to > get the > compression type for your file. > It supports bzip2, xz and gzip, what if I want to make let's say rar available to every application that is using KArchive?
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
