MobileRead Forums - View Single Post

pazos · 11-10-2022, 04:42 PM

Hey, I'm wrong all the time

. That makes me thing I'm good assuming errors and trying to correct them. Respect!

Back to topic:

The flat view / library view has been brought many times to KOReader but unfortunately none of the interested parties did contribute the code to make it happen.

Is not particulary easy given how KOReader works.

AFAIK all the firmwares beyond Kindles and Android devices do scan and parse books after each USB connection to the computer. These snowflakes have some sort of daemon running all the time, indexing documents as they come.

Since we're not Google nor Amazon, and we don't have full control over the usb stack in all the platforms we support the best we can do is to provide a button to let the user to scan documents at any given time.

Which leads to the not so fun part:

KOReader/LuaJIT is mostly single threaded. Lua has coroutines, but they're inferior to posix threads for this kind of task.

I would assume that a proper implementation would be writting a daemon running on a different process that starts its work and notifies on termination.

That daemon could repurpose current metadata extraction or implement their own for extra speed.

Even then we need to talk about the big elephant in the room: the UI.

KOReader implements its own UI stack. I would say than 80% time of a plausible ETA would end in writting widgets and joining them in a coherent interface. But that's just my opinion, maybe because I'm not good with UIs

IMO writting a gui that acts a view for items in a grid but doesn't implement the model/controller is the best way to tackle the task.

That makes possible to write different implementations where different providers provide a model of an item.

I'm assuming 99% of people who ask for a library view are calibre users and we already have a calibre plugin. That calibre plugin just need to decode base64 thumbnails to a cache and it is ready to act as a model/controller for the view.

See https://github.com/koreader/koreader...ent-1020707164 if you want to expand further on the idea.

11-10-2022, 04:42 PM	#6
pazos cosiñeiro Posts: 1,406 Karma: 2451781 Join Date: Apr 2014 Device: BQ Cervantes 4	Hey, I'm wrong all the time . That makes me thing I'm good assuming errors and trying to correct them. Respect! Back to topic: The flat view / library view has been brought many times to KOReader but unfortunately none of the interested parties did contribute the code to make it happen. Is not particulary easy given how KOReader works. AFAIK all the firmwares beyond Kindles and Android devices do scan and parse books after each USB connection to the computer. These snowflakes have some sort of daemon running all the time, indexing documents as they come. Since we're not Google nor Amazon, and we don't have full control over the usb stack in all the platforms we support the best we can do is to provide a button to let the user to scan documents at any given time. Which leads to the not so fun part: KOReader/LuaJIT is mostly single threaded. Lua has coroutines, but they're inferior to posix threads for this kind of task. I would assume that a proper implementation would be writting a daemon running on a different process that starts its work and notifies on termination. That daemon could repurpose current metadata extraction or implement their own for extra speed. Even then we need to talk about the big elephant in the room: the UI. KOReader implements its own UI stack. I would say than 80% time of a plausible ETA would end in writting widgets and joining them in a coherent interface. But that's just my opinion, maybe because I'm not good with UIs IMO writting a gui that acts a view for items in a grid but doesn't implement the model/controller is the best way to tackle the task. That makes possible to write different implementations where different providers provide a model of an item. I'm assuming 99% of people who ask for a library view are calibre users and we already have a calibre plugin. That calibre plugin just need to decode base64 thumbnails to a cache and it is ready to act as a model/controller for the view. See https://github.com/koreader/koreader...ent-1020707164 if you want to expand further on the idea.