Koreader running on Kobos (all of them, hopefully!)

[NiLuJe]

I see LuaSocket pulling the right zsync control file, and that's the only device-dependent part, so, that, at least, works (which we knew already, since you do see the 'new version available' prompt ).

tar might be falling on its ass on Kobos, that's the next step.

Easy enough to check with a shell: as the same user than KOReader uses (root? not familiar with Kobos), and from the koreader directory (again, not familiar with Kobos ;p), run:

./tar cvf ota/koreader.installed.tar -C .. -T ota/package.index --no-recursion
echo $?

And report back .

[WS64]

@embryo, what does crash.log say?
Where are your books stored?

[embryo]

Originally Posted by WS64

@embryo, what does crash.log say?
Where are your books stored?

Crash.log

./luajit: error loading module 'defaults' from file './defaults.lua':
	./defaults.lua:148: unexpected symbol near '/'
stack traceback:
	[C]: at 0x00041881
	[C]: in function 'require'
	./reader.lua:9: in main chunk
	[C]: in function 'dofile'
	./koreader-base:22: in main chunk
	[C]: at 0x0000bd85

The books are stored at "/mnt/sd/.Books"
The full line I have is:
LIBRARY_PATH = /mnt/sd/.Books

What is the problematic symbol?

[NiLuJe]

That should probably be quoted. (i.e., LIBRARY_PATH = "/mnt/sd/.Books")

[WS64]

Did you by chance edit defaults.lua with a windows editor like notepad?
In that case the problematic character would be chr(10). In that case overwrite defaults.lua with the one from the package again and try again with a different editor.

[WS64]

Ahh, quotes, of course... In case I did not use quotes on the examples I will change that tomorrow

[embryo]

Originally Posted by WS64

Ahh, quotes, of course... In case I did not use quotes on the examples I will change that tomorrow

Yeap, that was it!
Now I can search.

Next problem.

When Calibre sends books to a device, is changing the Unicode characters to English equivalents.
There is no way around it.
The same happens when you 'Save to Disk', but here you have a way to disable this.
So I do that.
I 'Save to Disk' first and then copy the files to the reader by myself.

And now in the search results I get many "\u03b9\u03c7\..." characters.
Is the only solution to that to let Calibre convert the filenames?

Is it OK for the conversation about the metadata search problems to continue here or at this thread?

[NiLuJe]

@WS64: AFAICT, switching to a proper json decoder would be probably faster if there's a C backend, and handle the unicode issue properly.

EDIT: Barring that, looking at one should at least give you an example of how to handle escaped unicode sequences.

EDIT²: For example, dkjson's unichar function seems to handle it in a fairly concise manner.

> print(unichar(0x00e9))
é

[WS64]

Thanks, NiLuJe, that worked!
Just added this to GH.

@embryo, I also added chapter markersfor the mini bar (you can turn it on and off in defaults.lua) and added quotation marks to the default.lua comments.

Should all be in the next nightly.

[embryo]

Originally Posted by WS64

Thanks, NiLuJe, that worked!
Just added this to GH.

@embryo, I also added chapter markersfor the mini bar (you can turn it on and off in defaults.lua) and added quotation marks to the default.lua comments.

Should all be in the next nightly.

That was really quick!
Thank you!

And while we're waiting for the next nightly, I could add one more suggestion.

Searching for the metadata could lead to 2 problems.
- If you don't remember the exact 'Wording - Naming' of a tag, Author, etc or,
- The tag, Author, etc, is using Unicode characters that you can not enter by the keyboard.
(I'm still trying to find where the keyboard setup is, like the kbd.txt for vlasovsoft one, but even if I do put Unicode characters in there, some of them like punctuated ones can not be easily accessed).

A solution to this could be the presentation of all the metadata the query of the 'metadata.calibre' can produce, in a form of a menu (with the actual search in a menu entry of its own), as soon as the user enters the query.
Here is a screenshot of the FBReader's Library.

This way every menu entry could be a search of its own.
E.g. if you press 'Tags' you'll presented with a sub-menu having the names of all the tags the search can find.
Pressing the 'Fantasy' sub-menu will lead you to the search results with the books having the 'Fantasy' tag.
Menus with many entries like Titles, Authors and Series could lead to a sub-menu of groups by the first letters: A - B - C ... with an easy option (maybe in a single page?) to jump to a particular letter.
The "First Letter Grouping" could be an option to turn it on or off if you don't have that many books in your reader.

Well, I thing I was carried a little away with this ...
These are just suggestions from a user's perspective.
I know that it could be undoable from the programmers side, and I really do appreciate the work done thus far, but I had to ask.

[WS64]

I was thinking of menus with the metadata items too, I just don't know how to present them (like a popup menu or something like that.)


I just have enhanced the keyboard to display man umlauts, that should also solve some of the things you mentioned...

[embryo]

Just got 469 (not from the air, more like from the cable ;o) and the progress bar markers are looking good.
Thanks WS64!
Can we have a "DMINIBAR_PROGRESS_MARKER_SIZE" or something, to make it a little more visible?

Originally Posted by WS64

I just have enhanced the keyboard to display man umlauts, that should also solve some of the things you mentioned...

Actually, I need a totally different language.
With sergeyvl12's keyboard you can do it like that.

[WS64]

I'm not sure a marker_size would make sense without being also changed for every book. I have some books that have so many TOC entries that the progress bar right now is nearly useless since it is all black, while in general I agree it is pretty thin.

I think what koreader needs is a concept to edit way more settings while it is running.

If you want to manually make it stronger search edit
frontend/ui/widget/virtualkeyboard.lua
and change this value (line 40 on):

if #self.TOC > 0 then
for i=1, #self.TOC do
v = self.TOC[i]
bb:paintRect(x+(my_size.w-2*self.margin_h)*(v.page/self.last), y+self.margin_v+self.bordersize,
2,(my_size.h-2*(self.margin_v+self.bordersize)), self.bordercolor)
end
end

3 will do, I would not go much higher.

To the keyboard, well, we don't have such an easy to configure keyboard right now, sorry.

But again, you can edit one layout yourself, this is done in
frontend/ui/widget/virtualkeyboard.lua
from line 124 on.
I suggest you use columns 5-8 or 9-12 and overwrite the "world" and "Äéß" settings. Just enter your letters instead of the existing ones.

[embryo]

Originally Posted by WS64

If you want to manually make it stronger search edit
frontend/ui/widget/virtualkeyboard.lua
and change this value (line 40 on):
3 will do, I would not go much higher.

You mean frontend/ui/widget/progresswidget.lua, right?
I made the changes but nothing happened.
What I'm trying to achieve is to make it wider and minimize the margins around it, like the snapshot I uploaded, but it seems impossible.
Anyway, its not that important.
Its already acceptable.

To the keyboard, well, we don't have such an easy to configure keyboard right now, sorry.

But again, you can edit one layout yourself, this is done in
frontend/ui/widget/virtualkeyboard.lua
from line 124 on.
I suggest you use columns 5-8 or 9-12 and overwrite the "world" and "Äéß" settings. Just enter your letters instead of the existing ones.

Perfect!
Exactly what I was looking for.
Thank you.

[WS64]

Originally Posted by embryo

You mean frontend/ui/widget/progresswidget.lua, right?
I made the changes but nothing happened.

Yes, progresswidget, sorry.
The 2 is the width of the markers, you should see a difference!