Thread: JBPatch
View Single Post
Old 10-11-2012, 01:29 PM   #812
twobob
( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Týr
twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.twobob ought to be getting tired of karma fortunes by now.
 
twobob's Avatar
 
Posts: 6,586
Karma: 6299991
Join Date: Jun 2012
Location: uti gratia usura (Yao ying da ying; Mo ying da yieng)
Device: PW-WIFI|K5-3G+WIFI| K4|K3-3G|DXG|K2| Rooted Nook Touch
Okay I just read the entire JB Patch wiki page. Again.

"No effect" in the sense that the various specific classes that you are trying to address would be different ones on the KK. so whilst JBPatch may go ahead and attempt to patch a bunch of non-existant files - the net result would be zero changes.

I'll just quote the very end of the page
Quote:
Developing new Patches

JBPatch is only a framework for patches, and everybody is more than welcome to develop new patches. I will happily include such patches into the base distribution, if they are found to be useful. Here is a minimal description of how the general procedure to develop a new patch could look like:
  1. Identify an aspect of the Kindle which can be improved.
  2. Find out where exactly the code pertaining to that aspect is located in the Java classes. This is arguably the most difficult part of the entire procedure, as it requires to reverse engineer the existing Java classes. A few hints about this are linked from the first post of the JBPatch thread, and a few more can be found on the Kindle Touch Hacking page.
  3. Write a minimal patch to change some functionality at the previously identified locations. This is the second-most difficult part of the procedure, and will probably require a few iterations to get it right. You may want to test your changes on your development computer first (by modifying the "TestCurrentGoal" JUnit class, and by verifying that the output looks correct indeed), and then to test it on the Kindle by copying the patch to the device and restarting it, while watching the JBPatch log (/tmp/jbpatch.log). Hint: don't worry about localization, or about configurability, at this point.
  4. Once your patch is working correctly, the difficult part is over. You can now turn to the localization aspects (to make the patch appear correctly in the user interface; that's pretty easy), and possibly to configuration as well. Allowing for configurable settings isn't terribly difficult, it just requires a few more lines of code. You can always look at the source code of existing patches for examples. The hyphenation patch is a particularly good example to see how localization works, but the Cover View patch, the TTS patch, or the margins patch may be worthwile as well.
  5. Announce your patch in the forum thread!
So that is what I draw this conclusion from.

I think that this is a very exciting development (It being for a 3) and there are some options for UI IMHO.

: )

Last edited by twobob; 10-11-2012 at 01:34 PM. Reason: links to make life easy for future readers.
twobob is offline   Reply With Quote