KOReader advantages?

[Mercador]

Originally Posted by RangoX

I'd like to try KOreader but I don't understand what happens to the stock reader? Will I be able to switch between one and the other whenever I want? How?

KOReader become a link in the NickelMenu, you start it as you would start an app on your cellphone. When you exit the app, you return to the Kobo normal UI. It really worth it to try it imho, I'm just sad that I waited that long to switch.

[RangoX]

Originally Posted by NiLuJe

Nothing at all, is what happens to the stock reader .

Exiting KOReader will simply restart it, as will rebooting the device.

Originally Posted by Mercador

KOReader become a link in the NickelMenu, you start it as you would start an app on your cellphone. When you exit the app, you return to the Kobo normal UI. It really worth it to try it imho, I'm just sad that I waited that long to switch.

Thank you very much, I'll give it a try. By the way, does reading footnotes improve with KOreader?

[ps67]

Originally Posted by RangoX

Thank you very much, I'll give it a try. By the way, does reading footnotes improve with KOreader?

You have 3 choices: pop up notes, You can go to the page of the notes, or You can see the note at the bottom of the page You are reading (like a real book).

[Uncle Robin]

Originally Posted by the.Mtn.Man

it doesn't seem to play nicely with large books, so anything like a "complete collection" epub is going to be very slow to open and very slow to make formatting changes to such as adjusting margins or font sizes

This! I have been reading Delphi's Maurice LeBlanc collection on my Kobo, listed as 4854 pages, a 5.1MB file, and when I opened it for the first time in KOReader, I thought it had frozen, and had to restrain myself from trying a hard reboot. Ditto for every single adjustment I made trying to get it "just right" - font, font size, margins, justification. I lost between 30-45 minutes of reading time making the sort of adjustments that would take 5 minutes or so on Nickel.

Over the weekend I have spent more time in KOReader than in Nickel, and so far, I don't get the raves. Or rather, I get that the raves confirm it's not going to be my first choice.

It's a competent reader for sure, there's nothing wrong with it. But the features most rave about (Wallabag, ligatures, "real" page numbers etc.) are of no interest to me, and I DO miss being able to plug my Libra in and have Calibre with all its wonderful plugins available. I also REALLY miss the easy access to series and collections. Having to scroll through a File Manager listing all 650+ books by author is much less appealing than being able to go straight to my TBR, my Romance collection, etc, or to simply pick a book based on its cover.

I am going to read a few more books on it to try the stats that have been lauded, but so far, the impression it gives me is one common to a lot of FLOSS software - designed to be fun for those who love tinkering and customizing as an end in itself, but for those who just want to pick up a book and read, not so much.

[NiLuJe]

Originally Posted by Uncle Robin

I DO miss being able to plug my Libra in and have Calibre with all its wonderful plugins available.

Err, that should work just fine? (You'll just need to trigger a Library scan via NM the next time you're in Nickel for new books to get picked up).

Originally Posted by Uncle Robin

I also REALLY miss the easy access to series and collections.

That should also work just fine via a Calibre metadata search. (For series, at least; for collections, that depends on how yours are set-up, but if they're based on Calibre tags, there's a tag browser).

----

The rest was discussed in the sibling thread, so it doesn't come as much of a surprise .

I've also discussed the chunked vs. papyrus rendering tradeoff at length in the past... somewhere in a couple of those 11000 posts ^^.

[Uncle Robin]

Originally Posted by NiLuJe

That should also work just fine via a Calibre metadata search. (For series, at least; for collections, that depends on how yours are set-up, but if they're based on Calibre tags, there's a tag browser).

I can't see a way to filter those searches by "unread", "Date added" etc?

[NiLuJe]

Originally Posted by Uncle Robin

I can't see a way to filter those searches by "unread", "Date added" etc?

Yup. Because neither of those are a Series or a Tag ^^. Those come from other columns, either standard (date added) or custom (reading status).

They're *technically* in the on-device metadata dump, so they could be handled, but I don't personally see much use for the Date Added one (I don't *think* it matches the on-device file's ctime, for instance, and *that*, on the other hand, is a bit of data that might be interesting). The read status might be useful, but is trickier to handle: it's a custom column, so it'd need user input to set it properly (name & format), and it's not nearly as useful on its own, which means it'd only be useful for compound searches (i.e., search filters), which aren't currently supported .

EDIT: Some of those "date" columns could be useful as a *sort* method, though. But, again, not implemented yet ^^.

EDIT²: (Thinking out loud). In the interim, what might be easier to implement (both UI & code-wise) would be graying out read items from search results.

[Uncle Robin]

Originally Posted by NiLuJe

EDIT²: (Thinking out loud). In the interim, what might be easier to implement (both UI & code-wise) would be graying out read items from search results.

This would be a very useful enhancement. Also, thanks for confirming that, at least on this occasion, I had not missed some feature or functionality. I would have been happy to RTFM if only there were one - the wiki not exactly setting the benchmark for comprehensiveness and/or usefulness.

[davidfor]

Originally Posted by NiLuJe

Err, that should work just fine? (You'll just need to trigger a Library scan via NM the next time you're in Nickel for new books to get picked up).

But they don't really do anything useful if you don't use nickel. And calibre will not see the books on the device if you don't do the import. For those who only want to use KOReader, I recommend using either "Connect to folder" or the User Defined USB driver. Both of these will let calibre see and manage the books without looking at the database.

[NiLuJe]

@davidfor: Hmm, good point on the fact that the Kobo driver uses nickel's db to do the on-device check, I'd forgotten about that because I tend to actually do the import in between usbms sessions . (e.g,. I sync ko read status to the nickel db, so keeping it in sync is part of the work flow. Might not do it right after loading the books, but it'll happen eventually ;p).

@Uncle Robin: Yeah, doing a cursory pass over the wiki to make it slightly less depressing keeps getting pushed back down the TODO list, unfortunately...

[davidfor]

Originally Posted by NiLuJe

@Uncle Robin: Yeah, doing a cursory pass over the wiki to make it slightly less depressing keeps getting pushed back down the TODO list, unfortunately...

Hmm, write code or write documentation. I know which one wins here every time.

[Uncle Robin]

Originally Posted by Uncle Robin

I am going to read a few more books on it to try the stats that have been lauded

And the verdict on this one is an emphatic win for KOReader. Kobo's flaky "time to read count has long irked me, bearing no elation to its own more or less accurate count of clicks per minute (I use "click" because they're a real thing on my ereader, unlike pages).

In the attached shots, Kobo's click per minute count is pretty much spot on. But if that rate is used to calculate the time remaining, the answer should be 16.8 hours, not 44.

The KOReader stats are MUCH more accurate. At exactly 4 clicks per minute, the time taken to finish the book should be 12.366 hrs - VERY close to KOReader's estimate, very much unlike the Kobo count. The book is Calibre converted kepub too, so it's impressive that KOReader counts and extrapolates so much more accurately than does Nickel.

[pazos]

Originally Posted by Uncle Robin

This would be a very useful enhancement. Also, thanks for confirming that, at least on this occasion, I had not missed some feature or functionality. I would have been happy to RTFM if only there were one - the wiki not exactly setting the benchmark for comprehensiveness and/or usefulness.

A manual would be awesome, indeed. Much better than the wiki for new users.

The raison d'être of the wiki is documenting specific features. Most of these features are quite advanced, like dictionary support, keymapping or gestures.

Also, since KOReader is a very hacked up reader, nobody expects than the average user/contributor/maintainer actually knows (or wants to know) more than 10% of that extra stuff.

Personally I think new users are the best to write end user documentation, if that's something in the scope of the program. I would doubt it sometimes. It was a hacked reader for its author at first. Then others used (and hacked) it.

Mainstream, even in a niche product like aftermarket ebook readers, was never a goal. It was and still is an ebook playground. So no doubt why nobody writes end user documentation. Actual users are more interested in writing code or just use the program to read. After all they all know how to handle the program.

So my approach with the RTFM would be: some new user with genuine interest and a few hours of free time writes glue code on a few topics, and that, paired with some info of the wiki, makes a manual to read. See my suggestion

Once there's a manual it is way easier for others to tell the manual isn't good enough and suggest changes.

[NiLuJe]

@pazos: Yep! It'd be a great base for a dev actually familiar with the code in question to then do a quality check pass on top of that to fix mistakes or simplify things.

(That's essentially what I ultimately want to with the current wiki. I even had a slot in the schedule for it and everything, but then the new icons came along, and I went: well, if I have to take new screenshots anyway, better wait for that to land... and then, well, shiny new thing happened, and happened, and happened... ;p).

[NiLuJe]

@Uncle Robin: A not necessarily obvious thing is that you actually control the initial state (e.g., what happens when you open a brand new book).

Each book is a blank slate, there's no cross-book tracking. Instead, there's a setting available¹ for the thresholds: a floor (if a page was shown on screen for *less* than this amount, it's not counted in the stats. The intent being ensuring skimming doesn't pollute the stats), and a ceiling (if a page was shown for *more* than this amount, the time is capped to this value. The intent being having spent time in the dictionary/wikipedia/menus/whatever doesn't skew the stats too much).

That's used to seed the initial computation of "time spent reading a page" (at 50% of the cap).

----

[1]: This is KOReader's unofficial motto: "there's a setting for it" .