Hello.
I have installed the JBPatch 2.2.1 and it works fine. It's incredible!! I have some suggestions for next versions (if ixtab can implement them):

- Fix the "cover view option" without Facebook sincronization (it's tedious to convert the books again).
- Include the "disable ads patch" in a bundle version.
- Show the JBPatch icon as an option in the main menu or as a submenu inside the Launcher menu, instead of an icon in the Home.
- Include in bundle the "custom screen saver hack" with two configurable options: choose a folder with images or put as screensaver the cover of the last viewed book.

I might look into this some time in the future (or I might not), so don't hold your breath. However, if anybody has some information about where this flag is "stored" inside the mobi files, feel free to comment. The more information is available, the higher the likelihood of this quirk being fixed somehow.

Quote:

Originally Posted by victor_2203

- Include the "disable ads patch" in a bundle version.

Not going to happen.

Quote:

Originally Posted by victor_2203

- Show the JBPatch icon as an option in the main menu or as a submenu inside the Launcher menu, instead of an icon in the Home.

Done, see the attached file. If you wish to completely hide the JBPatch program from home, you can use Collections Manager to do so.

Quote:

Originally Posted by victor_2203

- Include in bundle the "custom screen saver hack" with two configurable options: choose a folder with images or put as screensaver the cover of the last viewed book.

Not going to happen (well, at least, I personally won't look into it). Reasons:

Changing screensavers requires modifications to the root filesystem, which is against the spirit of JBPatch.

Screensavers are handled completely outside of the scope of JBPatch (the Java part if the framework). The only thing where it could come into play is for determining which book was last read, but that can very likely also be determined differently.

@ixtab: the cover/thumbnails thingy is probably not pretty... AFAICT, as soon as there's an ASIN specified (exth 113), it will try to download the thumbnail from Amazon via HTTP for this ASIN (it's visible in the logs, might be run as part of the indexing/catalog process).

The workaround Calibre implements is sending said thumbnail at the same time as the book. The FW sees the thumb, doesn't try to re-dl it. It obviously doesn't implement this for the cover view, only the thumbnails .

(And the 'enable share' thingy just prevents Calibre from injecting something in exth 113 if it's not already set. On the other hand, this field is *always* set for books purchased on Amazon. I'd be curious to know if those end up having a proper cover, wireless off or on...).

I haven't looked at the difference in thumbnails vs. coverview handling, but I'm guessing it's in the same spirit... (Do they end up cached somewhere in /mnt/us/system, like the thumbnails?)

It includes the latest hyphenation patch (no more need to download it separately), and a fixed version of the cover views patch.

More info about the cover views:
Earlier versions required books exported via Calibre to have the "enable Facebook sharing" option set, in order to have their covers displayed. This is no longer the case: every book which actually has a cover should be displayed correctly.

If you have books on your device for which covers are not shown (yet), the simplest procedure is to just re-upload those books from Calibre.

One more thing: since a few people have requested something like a "tip jar", I decided to just give it a go, and to see how this ends up. I'm counting on you guys - I hope you value the effort enough to donate a little something... Anyway, you can donate using Payza or Paypal (which also accepts Credit Cards from non-Paypal members) at ixtab.tk - thanks!

I went to donate (even though I don't have a KT, I can still appreciate his work, right?) but I realized my PayPal account had a balance of $0 (I haven't used it in a while....), so as soon as I get more internet coins, I will throw some your way, ixtab.

He will get some support for beer, of course.
Especially with the actual temperatures in Germany he will need some bottles to cool his head to keep it in conditions for further development of his hacks.

More info about the cover views:
Earlier versions required books exported via Calibre to have the "enable Facebook sharing" option set, in order to have their covers displayed. This is no longer the case: every book which actually has a cover should be displayed correctly.

If you have books on your device for which covers are not shown (yet), the simplest procedure is to just re-upload those books from Calibre.

I'm one of the users who can't show the cover for the books previously transfered in the kindle. I used to transfer the books using the Windows explorer (not Calibre). Due to this reason I can't see the covers. Is there any solution to show the covers for the books which are in the Kindle already, instead of transfer all the books again? Would it be possible in the future?

I just noticed something in the hyphenation patch that can make it perfect: the space before the hyphened word sometimes seems to be smaller than the spaces in the same line. Do you think it is an easy fix? Thanks again.

Hmm...
Sounds like justification is applied prior to hyphenation (it would almost have to be, to determine if the line is too long).
It might be fixable, but would probably not be pretty to code.

I leave the details to the author's reply.

It is (from a coding standpoint) similar to the not justifing and hypenating of the last line of the page.
What do you do with any over-flow if that is the last page of the document?

Also related, not only do you typically not justify the last line of text, but something similar is done when the text wraps to a new page.

I worked on a word processor in the olden (minicomputer) days of computing. We called last lines wrapped to a new otherwise empty page "widow lines". We had a rule that the last TWO lines of text must get wrapped to the last page to prevent widow lines. That created a much more pleasing-to-view document. Perhaps something similar could be applied here.

Text justification actually has a lot more rules than these two mentioned here. We had a rather large book of rules, many of which controlled text justification. It is not as simple as you would think. One example that comes to mind is that you do not wrap a proper name to a new page, because it is capitalized and looks like the beginning of a new sentence when at the start of a new page. Beginning a page with a lower-case letter is one of the clues that tell us to seek the beginning of the sentence on the previous page when thumbing (leafing/browsing) through a book. There are more rules like this, and some rules have exceptions, and the exceptions have exceptions (such as when wrapping indented text).

Text justification actually has a lot more rules than these two mentioned here. We had a rather large book of rules, many of which controlled text justification. It is not as simple as you would think. One example that comes to mind is that you do not wrap a proper name to a new page, because it is capitalized and looks like the beginning of a new sentence when at the start of a new page. Beginning a page with a lower-case letter is one of the clues that tell us to seek the beginning of the sentence on the previous page. There are more rules like this...

In truth, it is much more complicated than I made it out to be.

If I can translate my own post:
Just be happy with the way it works, ignore the width of the last space on a justified line and the non-processed last line.
Anything else would probably double or triple the amount of code.