Sorry for the late response. I was busy with my bread work recently. But now it's time for me to fulfill my promise.

Good to see you back :)

I spent some time to investigate the possibility, and realized KOReader is becoming a huge system with too many functions in one binary. And a tiny error can eventually break the entire system. From my own opinion, this is not good. I prefer the way Unix works - the combination of small and focus tools.

Can't agree more. I have been thinking of splitting out the UI and rendering code apart for awhile. It will be a big win for KOReader. This way, UI crash will not crash the whole reader and the UI loop will not be blocked by the rendering job. It also makes it possible to plug in other UI frontends written in any language. A UI frontend can even connect to the headless reader core remotely through network.

So instead of adding a input method - as this by mentioned, instead of inputting Chinese, searching books with Chinese names is more important - I would suggest to use an index file. Then we can use background tasks to index file names or even file contents without changing KOReader core logic.

Hm.. I think indexing and input method are two separate issues. If that's what you want to explore, we should move the discussion to a separate issue. You should also join effort with @chrox on the index design since the new KOReader home might need to introduce indexes too.

And besides indexing files, I would like to add another background task to export book marks and comments to a single file, as Kindle does.

We should also evaluate various solutions for setting up background task in Lua. Lua does not have good builtin support for setting up real parallel background tasks.

Uh oh!

Uh oh!

FR:add chinese input method #1938

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions