Quote:
Originally Posted by refj
Thanks again tshering.
I've been working on these changes for koreader and noticed a couple of problems with $dontTamperwithFrontlight in KSM. (a) The meaning was inverted: The code changes the value of the frontlight when this variable is set to "true" and (b) it wasn't used everywhere I believe it should.
For this reason I've put together a patch that (a) fixes this and also (b) allows koreader to be aware of and delete "onstart/nickelkoreaderloop.sh" to end the koreader-nickel / nickel-koreader loop. https://gist.github.com/dset0x/a02f4ef0ff1897608e15
(Edit: By the way: why are "trilogy" and "pixie" excluded from this?)
Please let me know if you see any issues with it. It would be great if it could made it to the next KSM release. |
Thank you for your interest in KSM. In response to your posts #68 an #72, I will introduce running user scripts before and after starting nickel. So that users can easily use scripts like that posted in #72 without having to do modifications after each KSM update.
As for your suggestions in #74, I am currently a little under time pressure and cannot carefully go through it now. Therefore I might misunderstand some points and will only make some quick remarks
One point, I think, is that we differ in our understanding what the expression "dontTamperwithFrontlight" is meant to convey. I meant it to express that KSM should restore the original state of the light intensity (as it was after powering on and before KSM might have changed it, that means "0") before passing control to another application , since otherwise I would have to make changes to the configuration files of nickel and older versions of koreader. If you can live with this understanding of "dontTamperwithFrontlight", there is not need to change all "false" to "true" and vice versa.
Currently, with the default setting (dontTamperwithFrontlight=true), KSM switches off the light before passing control to nickel or koreader, and these applications set the light intensity according to the settings of their configuration files (if there are those settings). Therefore, if you decide to make koreader read and change the light settings of Kobo eReader.conf, it should still work as you intend without changing the KSM files, and this would not create problems with older versions of koreader (which do not change the setting in Kobo eReader.conf). Before returning control back to KSM, I think it is better to restore (as it is now done) the light intensity according to the KSM settings independent of the value of dontTamperwithFrontlight, since otherwise you would have to inform KSM about the current light intensity by writing to a config file, and KSM would have to continually read this config file.
By the way, how can I get the concerned modified lua files for testing?