Kindle -- KOReader: a document reader for PDF, DJVU, EPUB, FB2, HTML, ... (GPLv3)

[jhh]

Ok, @NiLuJe and @ilovejedd, thanks a lot for your work so far!

[Frenzie]

Originally Posted by NiLuJe

Can you try this random shot in the dark patch (based on the fact that the KT4 output looks eerily similar to the one from Kobo's Mk. 7 devices):

That can't work. For a quick test, it should be something like this. (See here why not.)

diff --git a/frontend/device/kindle/device.lua b/frontend/device/kindle/device.lua
index 501d0735..2505f8dc 100644
--- a/frontend/device/kindle/device.lua
+++ b/frontend/device/kindle/device.lua
@@ -755,6 +755,7 @@ function KindleBasic3:init()
 
     Kindle.init(self)
 
+    self.input.snow_protocol = true
     self.input.open(self.touch_dev)
     self.input.open("fake_events")
 end

[jhh]

Originally Posted by Frenzie

That can't work. For a quick test, it should be something like this. (See here why not.)

diff --git a/frontend/device/kindle/device.lua b/frontend/device/kindle/device.lua
index 501d0735..2505f8dc 100644
--- a/frontend/device/kindle/device.lua
+++ b/frontend/device/kindle/device.lua
@@ -755,6 +755,7 @@ function KindleBasic3:init()
 
     Kindle.init(self)
 
+    self.input.snow_protocol = true
     self.input.open(self.touch_dev)
     self.input.open("fake_events")
 end

I've modified \koreader\frontend\device\kindle\device.lua according to this patch and now it works perfectly!


(I don't have account at github so I won't comment there.)

[Frenzie]

Great! As soon as #5071 is merged it'll show up in the following nightly. Until then (in one or two days) it'd be best not to update.

[NiLuJe]

Duh. Stupidly simple indeed! Thanks, Frenzie!

[shamanNS]

Originally Posted by Frenzie

Not only is it not a syntax error, but removing trailing commas is bad practice.

return {
    ["cre_header_status_font_size"] = 40,
    ["copt_line_spacing"] = 110,
    ["disable_double_tap"] = true,
    ["copt_render_dpi"] = 300,
    ["start_with"] = "last",
    ["disable_kobolight"] = true,
    ["cre_header_status_font_size"] = 30,
    ["full_refresh_count"] = 12,
    ["larger_tap_area_to_follow_links"] = true,
    ["copt_b_page_margin"] = 10,
}

If it was not obvious I was referring to that single comma marked in red color.
So, are you telling me that Lua (or whatever language's 'data structure' / collection/list/array type that code snippet represents) is different than almost any other language under the Sun (even CSS properties list! respect those same conventions) where any type of "enumerating stuff" shouldn't end with a comma as that results in syntax error or parsing error?
Even when returning multiple things as separate objects you wouldn't end that statement with a comma.

[pazos]

It is a bad practice because a) it isn't needed and b) can cause problems if someone adds a n+1 element to the returned table.

It is like in C, where

if(something) return true; else return false;

is valid but a bad practice because in the moment of extending one of the statements it will become non-valid.

So unless you're sure that you always want a single return statement then the following is recommended

if(something) {return true;} else {return false;}

We can argue that braces are not needed in this particular example, like the comma in your sample case.

[shamanNS]

I personally hate people that are omitting curly braces for single statement if/else blocks just as much as I hate people that are omitting parentheses when assigning "arrow functions" that take only one argument to a variable or a constant (even though that particular case is mainly "just" offence in regards to code readability /glanceability. )



But this comma convention thing (in most language that is not optional...) is one of the rare things that are shared between most of the languages... or so I believed

[Frenzie]

Originally Posted by shamanNS

So, are you telling me that Lua (or whatever language's 'data structure' / collection/list/array type that code snippet represents) is different than almost any other language under the Sun (even CSS properties list! respect those same conventions) where any type of "enumerating stuff" shouldn't end with a comma as that results in syntax error or parsing error?

It's not a syntax error in Java (although it used to be at some point in now ancient implementations), JavaScript (unless you still need <=IE8), C#, Python, Ruby, Perl, PHP, etc. And of course it's not a syntax error in Lua either.

If I'm not mistaken, C89 and C++11 allow for it too. Why older C++ wouldn't… I have no idea.

Originally Posted by pazos

We can argue that braces are not needed in this particular example, like the comma in your sample case.

Yup, I'm always annoyed when I come across if statements without curly braces. Not because they are necessary as written because obviously they're not right there and then, but because I have to go about adding braces first instead of just quickly adding whatever I want to add.

Besides avoiding some hopefully minor annoyance (although with curly braces you can get undetected wrong behavior), both curly braces and trailing commas have the diff issue, in that you get some useless noise in your diffs. Again not a big deal, but still a minor annoyance that's nicer to do without.

So:

1. Fewer unintended errors, whether benign (syntax) or harmful (behavior).
2. Cleaner diffs.
3. Less effort. You could see this as a restatement of 1 and 2, but not exactly. I think I'm fairly safe these days from harmful errors introduced by 1 (through bad experience!), but I'm still annoyed at the minor effort of having to add braces or commas. You could also sort the list alphabetically using your editor if desired without running into 1, so I think it's worth making it a separate point.

Therefore languages that don't allow for trailing commas slightly annoy me.

CSS is a bit different though, depending on the specifics. I'm not generally annoyed by it.

Originally Posted by shamanNS

I personally hate people that are omitting curly braces for single statement if/else blocks just as much as I hate people that are omitting parentheses when assigning "arrow functions" that take only one argument to a variable or a constant (even though that particular case is mainly "just" offence in regards to code readability /glanceability

I think it's fine (for readability, anyway) if it's indented properly. To take the code from above:

if(something)
  return true;
else
  return false;

However, the problem now becomes that the indentation is misleading.

if(something)
  bla;
  // this is always executed
  blabla;

In that sense the way Python works is nice, although mostly it annoys me. I really like being able to do something like:

if (something) {
  indented();
quick_debug();
  indented_orig();
}

I think that makes it easier to work with.

tl;dr I prefer Lua over Python in many ways even though they seem superficially similar, and this is one of them.

[aaronwi]

Is there a way to make koreader the default opener for files on the pw2? seems quite tedious to open kual then koreader, then file manager, and go through author folders to find the file.

[NiLuJe]

That'd be KPVBooklet, which is documented in the GitHub Wiki, and should behave mostly fine (spoiler alert: never used it myself) as long as you stay away from FW >= 5.8

[makara]

On the latest version 2020.01, the menu items "Autosuspend timeout" and "Autoshutdown timeout" disappeared. Version for Kobo and for Kindle.
In the forum thread for Kobo, I have already talked about this problem. Everything worked out there, thanks PAZOC. But for the Kindle PW2 it doesn’t work. No plugins "Autosuspend timeout" end "Autoshutdown timeout" listed.

[Frenzie]

That's correct, it's only enabled on select devices:
https://github.com/koreader/koreader...main.lua#L3-L5

[makara]

Too bad there is no for KPW2. I hope someday will be.

[NiLuJe]

PRs welcome .

(Kindles are known to have some wonky rtcs and/or a couple of 'em in some cases, which would make supporting more than one specific model potentially non-trivial).

Plus, the fact that the stock system is still alive behind us would *probably* render this kind of thing inoperable anyway ^^.