Quote:
Originally Posted by vjjustin
I modified inlinedictionaryview, dictionary and textedit variables. I also modified margins/other settings. Is there any other variables I need to change?
|
If you've created a patch you're happy with there's no "need" to experiment any further - unless, of course, you're enjoying the experiments
My contribution to GeoffR's nickel.patch `Dictionary frame size - beta8` code includes changes to InlineDictionaryView, #dictionary, #textEdit, #header, #footer. I changed the last 2 to reduce the height of the dictionary pop-up header and footer. Kobo do l-o-v-e their large headers and footers
If you want it I can PM you a copy of the updated CSS stream I used to create it.
Quote:
Originally Posted by vjjustin
There is a delicate balance between how/what can be changed without braking the code. And I don't exactly understand what each of these variable do or how to modify without breaking the code. Trial and error takes a lot of time.
|
I can't argue with any of that
A user guide of variables/functionality would be very useful to patchers, but sadly will never happen.
Quote:
Originally Posted by vjjustin
So, as you said may not be efficient to do this after every update. Any pointers welcome.
|
The amount of work involved each time the firmware changes depends on how you are applying your nickel patches.
- If you use GeoffR's makepatch utility to convert each individual pipcat-style nickel patch into a GeoffR-style nickel patch (`Dictionary frame size - beta8` being just one example), then the nickel.patch code will survive a firmware update as long as Kobo didn't make changes to the contents of that particular CSS stream. The CSS stream number/location doesn't matter.
- If you do all your nickel patches directly using the pipcat method then you have to revisit your patches for each new firmware. Even if the content of a CSS stream doesn't change, the CSS stream number/location (e.g. /* found: 80 (zlib) pos: 54f79e */) always changes.
Option 1 is better once all your nickel tweaked values are finalised. It's really the only option if you want to share individual patches with the typical non-techie MR member. The downside is it's not possible to let users customise the nickel patch with their own tweaked values.
Option 2 is much faster when you're experimenting, especially if you're changing a lot of different nickel CSS streams. You don't need to be nearly so careful maintaining the exact length of the original CSS code. Also, one of the major nickel CSS streams is so large that if you want to tweak it (which I do to change the look of the MyBooks list) it wouldn't be practical to convert it to a GeoffR-style patch.
You can't easily mix options 1 and 2, you need to pick one or the other.