KoboPatch WebUI: customization (NickelMenu, KOReader) and patching via your browser

[Phil_C]

Originally Posted by MrSilverstrike

@Phil_C: I got this working. You can try out the feature on the preview at:
https://kp-dev.nicoverbruggen.be

It's accessible via the "Advanced" section below the patch selector.

You normally need to put in the destination path for the files manually, but fonts are automatically detected and the path is prefilled for an easy "sideload fonts to the system partition" experience.

(I've successfully used it to patch in some of my own fonts, which seems to work fine. If you want to undo it, removing these patched files still needs to happen via telnet or SSH, as you can only zero out patched files to "disable" them.)

This is looking really great. One more request and a question:

I have a hyphenation dictionary that is installed by the Files section of kobopatch.yaml (like the fonts). This sends the dict to usr/local/Kobo/hyphenDicts/. If this could be added to your Web flow, it would take care of my only remaining need.

I created the patch zip without connecting the Kobo, so it seems I would have to start from scratch if I want to do some new tweaking via the Web UI. True? But is it also true that if I connect the Kobo next time, my previous settings would be picked up from the .json that was copied to the device from the first effort?

Thanks for your work on this. It's super easy to use.

EDIT: Never mind! I did some more fiddling and answered my own questions. You mentioned that a path for additional files could be entered manually, but I missed it. I've experimented with multiple updates to one device and everything is working well. Another device will follow. Excellent!

[Phil_C]

@MrSilverstrike

There is one patch missing for the Clara BW. It is a special patch created by @jackie_w because "Remove line from bottom tab bar" does not work on this model.

Remove line from bottom tab bar via CSS:
  - Enabled: no
  - Description: Removes the line from the top of the bottom tab bar
  - FindZlib: "#activeTabLine" # qss/MainNavButton.qss
  - ReplaceZlibGroup:
      Replacements:
        - {Find: "solid", Replace: "none"}

This works on the Clara BW. Not sure about other models. I hope you can add this to your Web UI.

EDIT: This patch goes in nickel.yaml or maybe your Nickel Custom, not libnickel.yaml.

[JSWolf]

Originally Posted by MrSilverstrike

This already happens!

Currently, a manifest is stored in the (hidden) .kobopatch-webui folder at the root of the drive if you use "Connect to my Kobo" via USB and patch your device.

The manifest contains information about the patches you last chose, and you can "re-apply" the patches that you chose before if you attempt to go through the flow again.

The NickelMenu flow works the same way (it also generates a manifest) and there's a logs folder in there too for everyone who wants to see exactly what the webapp did to their device.

If this manifest is used for a new firmware and any of the patches no longer work, does the user get notified which patch(s) no longer work? Also, can the site be made to email users when any patch is found not to work and and are fixed to work?

[MrSilverstrike]

@Phil_C: Thanks, I'll make sure to add this later this week.

@JSWolf: The user can see which patches don't work due to the blacklist but the user isn't informed about broken patches. I think I can improve that, actually. A message after pressing "Restore patches" with an overview of which patches are known to fail (now) for the latest version might be useful. Currently the blacklist only applies to the latest firmware version, which is actually not communicated that well.

Sending email is something I generally don't do with my web apps for various reasons. Since everything is under version control, you can see whether something has changed in terms of compatibility by checking the blacklist history itself here: https://github.com/nicoverbruggen/ko...blacklist.json

If items are removed from the file, that means that patches have become compatible! The last time I updated the patches when you told me they'd been updated, and you can see that's what happened

[JSWolf]

Originally Posted by MrSilverstrike

@Phil_C: Thanks, I'll make sure to add this later this week.

@JSWolf: The user can see which patches don't work due to the blacklist but the user isn't informed about broken patches. I think I can improve that, actually. A message after pressing "Restore patches" with an overview of which patches are known to fail (now) for the latest version might be useful. Currently the blacklist only applies to the latest firmware version, which is actually not communicated that well.

Sending email is something I generally don't do with my web apps for various reasons. Since everything is under version control, you can see whether something has changed in terms of compatibility by checking the blacklist history itself here: https://github.com/nicoverbruggen/ko...blacklist.json

If items are removed from the file, that means that patches have become compatible! The last time I updated the patches when you told me they'd been updated, and you can see that's what happened

I thought of one thing that can be done. When someone loads the manifest, it tells the user which patches no longer work and which now work if anything has changed.

Another thing is to have a section that show new/newly working and non-working patches.

Then you won't have to do any emailing.

[MrSilverstrike]

Originally Posted by JSWolf

I thought of one thing that can be done. When someone loads the manifest, it tells the user which patches no longer work and which now work if anything has changed.

Another thing is to have a section that show new/newly working and non-working patches.

Then you won't have to do any emailing.

These are good ideas, I'll see what I can do to add these.