Cbz cover

[Boris]

Hi.

I'm trying, emphasis in trying, to extract the cover of cbz files.
When importing, it should extract the first file from the zip file,
change it's size, and save it to the cover folder.
There is a method in the Book model named fetch_cover, that retrieves
the cover from an online service.
Maybe I could put the code there, looking if is a cbz file, and
extracting the file, etc, but I don't think the model is a good place
to do file manipulation.
What I'm asking is, what would be the best place to put this code?
There is a cbzparse class, that is used in the cbzviewer. I was
thinking on adding a fetch cover method to this class and then using
it in the model to get the cover. Is this a good approach? cbzparse is
expecting a filename, which I have in the model.

Regards

Mario Pozzo

[Roberto Alsina]

Yes, the covers stuff is completely backwards, and needs refactoring.

[Boris]

I see that there is a lot of commented code in the importer plugin. It
no longer uses the try_import method, so it won't call
book.fetch_cover, which is the method I'm modifying to get the cbz
covers.
I guess it was commented to disable the guessing when importing.
What would be the best way of enabling fetch_cover? With an if to see
if is a cbz?

Regards

Mario

[Andrés Gattinoni]

> I see that there is a lot of commented code in the importer plugin. It
> no longer uses the try_import method, so it won't call
> book.fetch_cover, which is the method I'm modifying to get the cbz
> covers.
> I guess it was commented to disable the guessing when importing.
> What would be the best way of enabling fetch_cover? With an if to see
> if is a cbz?

I think the cbz-specific code should go in the cbzparser.
After that we should re-think how we will manage covers (in relation
to issue 17).
I'm not very happy with having a lot of non-database code on the
model, but we will need to determine where to put the code that
decides where to get the cover from (the file itself, calling the
appropriate parser, or the internet using guessers).

[Boris]

2011/2/15 Andrés Gattinoni <andresg...@gmail.com>:

I agree that the parser should take care of the format specific functions.
I don't like either that cover has the id number as name, but I can't
think of a better way right now.
Attached is a patch for the importer, where I added a check to see if
it is a cbz, so I can get the cover using the cbrparser. Also in the
patch are the modifications to CbzDocument to get the cover. I had to
add an import of Pil, I hope that's ok.

Suggestions are welcome, as I'm still a noob with Python.

[Roberto Alsina]

On 2/15/2011 4:23 PM, Boris wrote:
> I agree that the parser should take care of the format specific functions.
> I don't like either that cover has the id number as name, but I can't
> think of a better way right now.
> Attached is a patch for the importer, where I added a check to see if
> it is a cbz, so I can get the cover using the cbrparser. Also in the
> patch are the modifications to CbzDocument to get the cover. I had to
> add an import of Pil, I hope that's ok.

Why use PIL? We have PyQt! :-)

[Boris]

You know that saying... "when you only have a hammer, everything looks
like a nail ", well I knew the thumbnail could be done with PIL, so
I've used that.. :)

I'll start looking how to do it with PyQT.

Mario

[Boris]

same patch as before, but using PyQt instead of PIL.

Mario

[Roberto Alsina]

On 2/15/2011 5:06 PM, Boris wrote:
> same patch as before, but using PyQt instead of PIL.

Why don't you just commit in a branch? I have just granted you commit
rights :-)

[Boris]

Are you sure? :)

ok, updated branch issue25 , as it was the one where the request was.
hope that's ok.

Mario