JBPatch

[HiRsch]

alright, thanks for the answer. i changed the "text justification" options in calibres convert options from "original" to "justified". that does the trick.
cheers

[elRicharD]

ixtab, I have just updated to the latest jbpatch and I have to say that you managed to perfect what was perfect already. A truly godly endeavor indeed!

Amazon really needs to put you on their payroll.

Also, Spanish localization is AMAZING! Lol

Thanks man, you might get a beer sooner or later from me

[ixtab]

Just a short note:

thanks to all of you folks for providing feedback. Concerning the requests for new patches (either here in the thread, or via PM): even if you didn't receive a reply, rest assured that I do read and consider the requests.

That said, while the JBPatch core development is probably "stuck" on me (which is perfectly fine), JBPatch was always designed as an open framework for patches. I'm still wondering why it seems like nobody else (except for eureka, I know ) has ever even tried to develop a patch. Is it too complicated? Or too boring? Or just... too much effort?

I for myself am developing these patches because I find it to be both challenging and fun to mess around with the internals of the device. And yes of course, the only real reward is to see that the device behaves in a different way than what it was originally meant to. But that's what I consider much of the hacking to be about. Am I wrong?

Comments are welcome

[ixtab]

Originally Posted by kindleloh

Hi all,

I have updated the JBPatch to 2.3.1 and enjoy very much the process bar. Thank you very much ixtab. For this process bar I would like to ask for an additional feature.

The process bar is based on the whole book size. If a book has chapters, is it possible to only show the chapter statistic? I mean the process bar reflects the chapter length and the indication what is the remaining part.

It would be useful if a book has a lot of chapters and you want to read until next chapter. Then you need no painful scrolling within the book.

The progress bar patch was changed to take your request into account: download. In addition, a few other changes (hopefully for the better) have been made to the patch. BTW, the translations now need a minimal update, too

On a side note, @all: please do not ask for JBPatch features by contacting me directly via PM. Just post your suggestions in this thread. This will make it easier for everyone, because everybody can see what the current state is, and everybody can get involved.

[veezh]

I would personally like easier access to dictionaries other than the one I have selected as the default for a given language, preferably from the dictionary window after the Kindle has already looked up a word. It would also be great if, after I've selected the second dictionary, the original term I looked up could be looked up automatically (i.e. without me having to retype it) in the second dictionary.

The current way of accessing these dictionaries is long and complicated: exit the book you're reading, go to the end of the home screen, locate and open the Dictionaries folder, select and open the other dictionary(ies) you want to check and type in the term manually. This is often enough to put me off using other dictionaries while I'm reading.

[ixtab]

Here is another small patch.

The purpose of this one may not be immediately obvious, so... let's start with the description:

"This patch modifies the way that the collection content is counted and displayed on the home screen. This is only relevant if you are using nested collections. If this patch is enabled, the total number of items reachable from a collection (and its subcollections) is displayed. If it is disabled, only the items directly contained in a collection are counted."

If you still have doubts about what the point of all this is:

It's all about nested collections. If you don't use nested collections, there is nothing to worry about. But if you do, consider the following sample layout:

Classics
+- English
 + British
  - Doyle: The Adventures of Sherlock Holmes 
  - Doyle: The Hound of the Baskervilles
 + American
  - Twain: Adventures of Huckleberry Finn
+ German
 - Goethe: Faust - Erster und zweiter Teil
 - Schiller: Die Räuber
 + Kafka
  - Die Verwandlung
  - Der Prozeß
  - Amerika
+ Russian
 + Dostoyewsky:
  - The Brothers Karamazov
  - Crime and Punishment
  - The Idiot
 + Tolstoy
  - War And Peace

The "Classics" collection contains 3 subcollections - which is the number that is shown without the patch enabled. However, it effectively allows to access 12 books - which is the number shown when the patch is enabled. Similarly, the "German" entry will show "5" instead of "3", etc.

Download here.


PS: Yes, it may have become apparent from the above list -- I am a huge Kafka fan. If you ever wondered what "kafkaesque" means, just start reading! (Originals in German). Fortunately, all of these books are freely available without any Digital Restrictions Management.

[silver18]

Hi there!!!

First of all, thanks again for sharing your work and for constant updates!

I just installed last patch ("Modify Collection Count Behaviour") and I'm experiencing a problem...
When this patch is enabled, the GUI launcher seems to be slower.
This means it takes longer to refresh the screen when tapping on launcher and also when tapping on a item with a submenu in the launcher.
I can see the home screen in the time the launcher opens a submenu.
With that patch disabled, everything is a bit faster.

I tried uninstalling JBPatch and installing it again, then I tried enabling and disabling the patch and this happens only when the patch is enabled.

Here are more info:
Kindle Touch 5.1.2
JBPatch v2.3.1
Modify Collection Count Behaviour v2012-09-03

Thanks again!!!

[ixtab]

Originally Posted by silver18

Hi there!!!

First of all, thanks again for sharing your work and for constant updates!

I just installed last patch ("Modify Collection Count Behaviour") and I'm experiencing a problem...
When this patch is enabled, the GUI launcher seems to be slower.
This means it takes longer to refresh the screen when tapping on launcher and also when tapping on a item with a submenu in the launcher.
I can see the home screen in the time the launcher opens a submenu.
With that patch disabled, everything is a bit faster.

I tried uninstalling JBPatch and installing it again, then I tried enabling and disabling the patch and this happens only when the patch is enabled.

Here are more info:
Kindle Touch 5.1.2
JBPatch v2.3.1
Modify Collection Count Behaviour v2012-09-03

Thanks again!!!

Thanks for pointing this out. This is somewhat "expected", and doesn't really have to do with the GUI launcher as such. The problem is that the launcher changes parts of the screen, which in turn means that everything which is shown "below" is also repainted.

And if that happens to contain collections... the code to calculate the total amount is called every time. That code is relatively slow, because it needs to (recursively) look up stuff from the collections database, which is slow.

I will try and see if there is anything that I can do to optimize the code a bit so that it requires fewer round-trips to the database, but other than that, there isn't really much I can do about it, sorry.

[knc1]

Does the system allow you to write to that database?

Store the partial total of the number of leaves at each collection node (like storing the number of files at each directory node) as you traverse back up the collection tree.

When modify the collection tree, invalidate the node partial totals in that path as part of the process.

That way, you only have to recursively update the parts of the collection tree that happen to be invalid when you need the leaf and branch count(s).
Otherwise, the expansive traverse and count has already been done, just collect sub-totals as deep as required at the moment.

[ixtab]

So, here's an improved version of the patch.

This should be considerably faster than the previous version. It now requires only Θ(h) queries of the collections database, where the previous one required O(n). (where h=the height of the "collections tree" rooted at the given collection, and n=the number of leaf nodes of the tree).

It won't get any faster now
Let me know...

[silver18]

Originally Posted by ixtab

So, here's an improved version of the patch.

This should be considerably faster than the previous version. It now requires only Θ(h) queries of the collections database, where the previous one required O(n). (where h=the height of the "collections tree" rooted at the given collection, and n=the number of leaf nodes of the tree).

It won't get any faster now
Let me know...

This really improved the speed!

Thanks again!!

Spoiler:

To be honest, I don't use this patch as I don't have nested collections. I just pointed it out to check whether it was an impression or not!!
Anyway, thanks again!!!!

[kindleloh]

Hi ixtab,

thank you for the implementation of the chapter progress feature. I have tested it and found a minimal improvement: the 100 % is not at the end of the chapter but at the beginning of the next chapter. The first page is then showing the 100% bar and the second starts with a new bar. It seams that the condition to check 'the next chapter is entered' needs to be a 'less than' condition instead of 'equal' in the current position to TOC index. But its only a guess.

Buy the way if the information is available how many pages to turn to enter the next chapter, than it may be nice to draw page bullets into the progress bar (as equal in the book based view the chapter bullets). This could be a rough estimation, depends on information available. Then it would be easy visible how many pages until end of chapter.

And last but not least enjoy the beer, I have donate and thank you for sharing your knowledge and effort.

[ixtab]

Originally Posted by kindleloh

Hi ixtab,

thank you for the implementation of the chapter progress feature. I have tested it and found a minimal improvement: the 100 % is not at the end of the chapter but at the beginning of the next chapter. The first page is then showing the 100% bar and the second starts with a new bar. It seams that the condition to check 'the next chapter is entered' needs to be a 'less than' condition instead of 'equal' in the current position to TOC index. But its only a guess.

Thanks for the hint... I think that the newest version should fix it - and it was indeed almost exactly as you suspected.

Originally Posted by kindleloh

Buy the way if the information is available how many pages to turn to enter the next chapter, than it may be nice to draw page bullets into the progress bar (as equal in the book based view the chapter bullets). This could be a rough estimation, depends on information available. Then it would be easy visible how many pages until end of chapter.

This is not generally possible, because there are no "pages", and the concept of "position" (and even differences between positions) isn't easily translated into "number of screen refreshes"... sorry.

Originally Posted by kindleloh

And last but not least enjoy the beer, I have donate and thank you for sharing your knowledge and effort.

Thank you!

BTW, full disclosure: At this moment, I have received a total of $125.07 USD in donations (this is after Paypal has taken their ~10% fee), from 17 people (actually, more than one third of it was given by a single person; you know who you are - merci!)

So there will still be a bit of time until I can buy a Ferrari, but it might end up being enough for getting one of those new Paperwhite Kindles soon - so thanks again to everybody who contributed.

[MarvinO]

Just noticed this picture


Seems like the next kindle will have coverview enabled as a new feature

[knc1]

Nice example of sloppy image building.

Start by zooming in on the lower left corner where the invented screen image fails to meet the screen borders of that smart phone its overlayed on.