One-Click Install Packages for KOReader & Plato

[Elektron]

Tried installing this on my father's Forma (only Plato). When I launched Plato, nickel restarted. Why? TIA
Edit: Fixed now, ran the install script instead of "extract to." Worked like a charm

[baskerville]

Originally Posted by NiLuJe

I don't actually remember who came up with the final iteration, but, as far as I'm concerned, probably because I tend to prefer those.

I've updated the pattern in this post: it now uses the same quantifiers for the hidden directory name in both sides of main pipe.

Please also note that all the links in the comment for the new pattern expose the old pattern.

[baskerville]

Thanks for updating the pattern.

You might also want to update the two links to install.sh in the first post.

[NiLuJe]

@baskerville: That's ready, just haven't refreshed the packages just for that, as stuff basically works as-is .

[CouchBook]

Originally Posted by NiLuJe

@mirage: CRe (KOReader's main ePub engine) is not a chunked renderer. It takes the full book, processes it, and caches it. This essentially ends up as a giant roll of papyrus. Rendering a page is then as simple as picking a starting point from that roll.

This makes actually navigating a book extremely fast (moderately faster than the KePub render, slightly faster than any of Kindle's various renderers, massively faster than the RMSDK).

The obvious trade-off is that generating this first intermediate layer is time consuming (but most of it only affects the first time a book is opened, since this ends up being cached). That's the tiny progress bar you see in the top-left corner when opening a book.
The other trade-off is that changing anything that affects how the text will be laid out (on the book's scope, not on the page's scope) means a part of this intermediate rendering has to be thrown out and re-done (and, once again, tiny progress bar after a short while).

On a novel-sized, sanely coded fiction ePub, initial open should take a couple seconds at most, and re-layout roughly a second at most.

Larger books will affect that performance penalty adversely. As would tricky/degenerate code. Given how KePubs are made, a KePub will be very slightly worse off that a plain ePub.

Since you ultimately end up spending 99.99% of your time reading, and that every setting can be remembered as default, that's an acceptable trade-off in my book.

It might not be for you. Fair enough.

On the other hand, if your first instinct was to play with every setting affecting layout, and you happened to do that in a giant/poorly coded book, that definitely won't be any fun.
Try to do that in a short book first (e.g., KOReader's quickstart guide) to get your sea legs .

The problem is that on asymmetric devices, such as Kobo Libra H20, screen rotation is essential. Every time you switch hands, you want to rotate the screen by 180 degrees. For the book I'm currently reading it takes KoReader approximately 10-12 seconds to rotate the screen by 180 degrees (it performs to reflows, one for a 90 degree rotation and then another one). While I love KoReader otherwise, the slow screen rotation makes it unusable for me.

[NiLuJe]

There's an option for that . Namely, in Screen > Rotation, there's a "Lock orientation" (or something to that effect, not near the code or my Forma right now) option. That ensures the gyro only swaps between the invert of your current rotation, but inhibits orientation changes (so, typically, the hand swap on a Libra/Forma). And those rotations are free for CRe, as there's no layout change.

Sidebar: I'm assuming the Libra's gyro is tuned differently, because I'd need to be going very very slow for a hand swap to trigger an intermediate landscape rotation on a Forma.

[Carmelocotonto]

Hi, What is the correct one?. I want to put it into 'kobo ereader.conf'

This (\\.(?!kobo|adobe).+|([^.][^/]*/)+\\..+)

Or This (\\.(?!kobo|adobe).*?|([^.][^/]*/)+\\..+)

Thanks

[NiLuJe]

@Carmelocotonto: The first one would be the latest iteration (or, check the first post, it's been updated).

[Carmelocotonto]

Originally Posted by NiLuJe

@Carmelocotonto: The first one would be the latest iteration (or, check the first post, it's been updated).

Thanks. I tried both of them and all was ok, but I wanted to confirm it with someone. I will check the first post from time to time.

[kostiya]

Hi, this script is really helpful. thanx.
Now, is there a way to start directly KOreader without wasting 30 seconds to start Nickel, and using the switching menu?

[Alan_S]

For that, you need to use KSM 9 (but it probably won't work if you have too new firmware).

[kostiya]

Originally Posted by Alan_S

For that, you need to use KSM 9 (but it probably won't work if you have too new firmware).

Well, then too late for me.
Thank you.

[NiMa]

Originally Posted by kostiya

Hi, this script is really helpful. thanx.
Now, is there a way to start directly KOreader without wasting 30 seconds to start Nickel, and using the switching menu?

You could try modifying /etc/init.d/rcS to launch KOReader directly, but be careful; make a backup of your internal SD card before!!

[NiLuJe]

@kostiya:

Originally Posted by NiLuJe

@Mercador: Not OOB.

My stance on this, is: don't. On some devices, Nickel itself will do a few bits of low-level hardware initialization that we don't want to skip, and that would be extremely annoying to keep track of properly.

But, it's technically feasible, if you know what you're doing (c.f., Plato's standalone patch for inspiration.).

[kostiya]

Originally Posted by NiLuJe

@kostiya:

OK, got it.
I am not looking for trouble, hence I woun't.