Can I forgo commenting the default blank overrides: in the config and just append mine at the bottom of the file? (I won't ask you to make it commented out by default, because I know how confusing that might be to some users, as #110 just proved ).
Good question, something I have asked, too - including the commenting of the empty overrides.
I have submitted a pull request to allow reading a config file from a cmd line argument or stdin, and I would alter the question here: what besides the actual firmware zip file is version dependent? I see two times the version appearing in the yaml file: the `version` tag and the `in` tag.
Does the `version` tag carry any inherent meaning?
And if not, would it be an option (I can look at the code) to override the `in` tag with a command line argument? It really seems strange that everything looks so version independent but the version number still appears.
ResetBaseAddress()
Enabled: true
applying patch `tshering's BAD EYES adaptation (PROGRESIVE)`
looping over instructions
skipping non-instruction Enabled(), PatchGroup() or Description()
skipping non-instruction Enabled(), PatchGroup() or Description()
FindZlib("QWidget[small") | hex:515769646765745b736d616c6c
ReplaceZlib(0, "font-size: 91px", "font-size:91px")
ReplaceZlib(0, "font-size: 77px", "font-size:77px")
ReplaceZlib(0, "font-size: 74px", "font-size:74px")
ReplaceZlib(0, "font-size: 71px", "font-size:71px")
ReplaceZlib(0, "font-size: 62px", "font-size:62px")
ReplaceZlib(0, "font-size: 60px", "font-size:60px")
ReplaceZlib(0, "font-size: 57px", "font-size:59px")
ReplaceZlib(0, "font-size: 55px", "font-size:57px")
could not apply patch: ReplaceZlib: new compressed data is 2 bytes longer than old data (try removing whitespace or unnecessary css)
Fatal: Could not apply patch file src/nickel-BADEYES.yaml: ReplaceZlib: new compressed data is 2 bytes longer than old data (try removing whitespace or unnecessary css)
ResetBaseAddress()
Enabled: true
applying patch `tshering's BAD EYES adaptation (PROGRESIVE)`
looping over instructions
skipping non-instruction Enabled(), PatchGroup() or Description()
skipping non-instruction Enabled(), PatchGroup() or Description()
FindZlib("QWidget[small") | hex:515769646765745b736d616c6c
ReplaceZlib(0, "font-size: 91px", "font-size:91px")
ReplaceZlib(0, "font-size: 77px", "font-size:77px")
ReplaceZlib(0, "font-size: 74px", "font-size:74px")
ReplaceZlib(0, "font-size: 71px", "font-size:71px")
ReplaceZlib(0, "font-size: 62px", "font-size:62px")
ReplaceZlib(0, "font-size: 60px", "font-size:60px")
ReplaceZlib(0, "font-size: 57px", "font-size:59px")
ReplaceZlib(0, "font-size: 55px", "font-size:57px")
could not apply patch: ReplaceZlib: new compressed data is 2 bytes longer than old data (try removing whitespace or unnecessary css)
Fatal: Could not apply patch file src/nickel-BADEYES.yaml: ReplaceZlib: new compressed data is 2 bytes longer than old data (try removing whitespace or unnecessary css)
ResetBaseAddress()
Enabled: true
applying patch `tshering's BAD EYES adaptation (PROGRESIVE)`
looping over instructions
skipping non-instruction Enabled(), PatchGroup() or Description()
skipping non-instruction Enabled(), PatchGroup() or Description()
FindZlib("QWidget[small") | hex:515769646765745b736d616c6c
ReplaceZlib(0, "font-size: 57px", "font-size:59px")
ReplaceZlib(0, "font-size: 55px", "font-size:57px")
ReplaceZlib(0, "font-size: 50px", "font-size:53px")
ReplaceZlib(0, "font-size: 47px", "font-size:50px")
ReplaceZlib(0, "font-size: 46px", "font-size:49px")
could not apply patch: ReplaceZlib: new compressed data is 3 bytes longer than old data (try removing whitespace or unnecessary css)
Fatal: Could not apply patch file src/nickel-BADEYES.yaml: ReplaceZlib: new compressed data is 3 bytes longer than old data (try removing whitespace or unnecessary css)
ResetBaseAddress()
Enabled: true
applying patch `tshering's BAD EYES adaptation (PROGRESIVE)`
looping over instructions
skipping non-instruction Enabled(), PatchGroup() or Description()
skipping non-instruction Enabled(), PatchGroup() or Description()
FindZlib("QWidget[small") | hex:515769646765745b736d616c6c
ReplaceZlib(0, "QCheckBox[qApp_deviceIsTrilogy=true] {\n font-size: 19px;\n}", "QCheckBox[qApp_deviceIsTrilogy=true]{font-size:23px;}")
ReplaceZlib(0, "QCheckBox[qApp_deviceIsPhoenix=true] {\n font-size: 23px;\n}", "QCheckBox[qApp_deviceIsPhoenix=true]{font-size:27px;}")
ReplaceZlib(0, "QCheckBox[qApp_deviceIsDragon=true] {\n font-size: 29px;\n}", "QCheckBox[qApp_deviceIsDragon=true]{font-size:33px;}")
ReplaceZlib(0, "QCheckBox[qApp_deviceIsAlyssum=true] {\n font-size: 32px;\n}", "QCheckBox[qApp_deviceIsAlyssum=true]{font-size:36px;}")
could not apply patch: ReplaceZlib: new compressed data is 5 bytes longer than old data (try removing whitespace or unnecessary css)
Fatal: Could not apply patch file src/nickel-BADEYES.yaml: ReplaceZlib: new compressed data is 5 bytes longer than old data (try removing whitespace or unnecessary css)
I'm missing something?
I think all of them should work. (In fact, they do with patch32lsb).
I don't really know if I making once and again the same mistake, there is a problem with the compression method...
The fix for that is pretty easy. Just combine more of the ReplaceZlib instructions into one long replacement. This is a side effect of the way I do replacements, where the instructions are all executed individually. This means each individual instructions needs to compress well enough. I'm working on fixing this though to make it more convenient.
I'd suggest you group every 4-5 replacements into one long ReplaceZlib. Have a look at some of the patches I converted for examples of this. If you want, I can help you with this one.
Good question, something I have asked, too - including the commenting of the empty overrides.
I have submitted a pull request to allow reading a config file from a cmd line argument or stdin, and I would alter the question here: what besides the actual firmware zip file is version dependent? I see two times the version appearing in the yaml file: the `version` tag and the `in` tag.
Does the `version` tag carry any inherent meaning?
And if not, would it be an option (I can look at the code) to override the `in` tag with a command line argument? It really seems strange that everything looks so version independent but the version number still appears.
That exists for 2 reasons. Firstly, in the future, I may do a check on the version for the downloaded firmware, especially with the recently misleading version numbers in the update zip. Secondly, I want users to consciously upgrade their patches, not just blindly copy and paste.
For overriding the in tag, it would be simple (just setting cfg.In). I would need to add pflag for command line parsing, so tell me before you make a PR, if you are planning to. I can do this myself if you want.
Location: Go with the wind (43°19'17.7"N 2°00'19.4"W)
Device: ka1
Quote:
Originally Posted by geek1011
The fix for that is pretty easy. Just combine more of the ReplaceZlib instructions into one long replacement. This is a side effect of the way I do replacements, where the instructions are all executed individually. This means each individual instructions needs to compress well enough. I'm working on fixing this though to make it more convenient.
I'd suggest you group every 4-5 replacements into one long ReplaceZlib. Have a look at some of the patches I converted for examples of this. If you want, I can help you with this one.
Device: ClaraHD, Forma, Libra2, Clara2E, LibraCol, PBTouchHD3
Quote:
Originally Posted by geek1011
... I want users to consciously upgrade their patches, not just blindly copy and paste.
I couldn't agree more with this sentiment. I'm all for convenience but, where hacking is concerned, the brain needs to be engaged.
I've now migrated all my personal patches to the .yaml format. I'm very happy with the result. The FindZlib function for nickel is a great addition to the patching portfolio.
@geek1011,
I do have a question. Am I right in thinking that preparing a patch for a nickel nozlib CSS stream is exactly the same as preparing a patch for one of the other 3 files? i.e. it's essential for find/replace string lengths to be maintained at all times.
All we need now is another new firmware so we can fully test the theory that it should be easier to prepare/apply patches in future
@geek1011,
I do have a question. Am I right in thinking that preparing a patch for a nickel nozlib CSS stream is exactly the same as preparing a patch for one of the other 3 files? i.e. it's essential for find/replace string lengths to be maintained at all times.
All we need now is another new firmware so we can fully test the theory that it should be easier to prepare/apply patches in future
Yes, maintaining string length is required for nozlib patches. In the future (maybe in a few months), I will probably implement css-specific functions to allow patching CSS without even bothering with string replacements or finding the correct stream (I might have mentioned the details somewhere above).
As for the new firmware, I also hope it comes soon, as I'm on vacation later this summer and I want to be able to be there when the new firmware comes out. GeoffR finally responded to my PM, and I've told him everything needed to release a new version, so it should work out fine even if I'm not available. Basically, you just make a new dir for the new firmware, you comment out the outdated patches, you update the ones you can, you check the build status, then you create a GitHub release. The zips are automatically generated and tested.
Preserving (some) custom patch options from one version to the next
One simple approach keeping some customised patch options from one firmware version to the next could be to implement a depends keyword, similar to the patch_group keyword: This could also be used for the current two-part patches, where each part would simply depend on the other part.
depends = `NAME`
means that the current patch depends on another patch called NAME also being enabled. If the current patch is enabled but NAME is not, then throw an error.
A patch XXX with a small number of discrete options A, B, C, could be split into a base patch XXX-base, plus three patches XXX-option-A, XXX-option-B, XXX-option-C that each depend on XXX-base. (If they are mutually-exclusive options then they could also belong to patch_group XXX-options.)
It wouldn't help with patch options that have a wide range of possible values, those would still need to be edited by hand each time, but I think it would work okay for patches such as:
For some other patches it would also be possible for individuals to create their own custom configuration patch that they keep, and simply paste it into the file with each new version, (or the patch tool could implement a method of including it automatically?), instead of editing the existing patch. This would be especially useful where the custom configuration patch could be made version-independent but the main patch could not. Examples of where this might be useful are:
`My 24 line spacing values`
`Custom reading footer style`
This could all be done with the existing patch32lsb tools, with the depends line commented out as with the patch_group line, but it would not give useful error messages when the dependencies were not satisfied.
I'll create some concrete examples later that might help explain it better.
Edit: Added a simple example for splitting up `KePub stylesheet additions` here.
Last edited by GeoffR; 07-15-2018 at 04:45 AM.
Reason: added link to `KePub stylesheet additions` example
That's a really good idea! I'll implement it sometime in the next few weeks. There's a bit of complexity due to dependency resolution though, but I think I will use topological sorting to deal with it.
Location: Go with the wind (43°19'17.7"N 2°00'19.4"W)
Device: ka1
Anyone knows how to manage special characters > and !?
I tried: \ (works for "),
|,>,
HTML Entity (#33 for exclamation mark),
Unicode block (u+0021 for exclamation mark)
...
Anyone knows how to manage special characters > and !?
I tried: \ (works for "),
|,>,
HTML Entity (#33 for exclamation mark),
Unicode block (u+0021 for exclamation mark)
...
07-14-2018, 04:24 AM
).
Similar Threads