KArchive design changes

[Pier Luigi]

2012/10/1 Mario Bensi <mbensi at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20121028/72907aca/attachment.html>