[refj]

Oh, thanks davidfor. That makes sense.

Originally Posted by tshering

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.

Hello. That would be pretty cool.

Originally Posted by tshering

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.

I understand now. You are right in that with this interpretation of `dontTamperwithFrontlight=true`both applications should still be able to apply their settings. I must had been doing something wrong in my code in koreader that tricked me into thinking that KSM changing the value of the frontlight being the problem. My KOreader modifications work fine now without patching KSM.

This leaves the `nkloopfifo` checking bits from my link above as a potential patch. (this and this)

Originally Posted by tshering

By the way, how can I get the concerned modified lua files for testing?

They're in unified diff format so you should be able to apply my patches with `patch` under UNIX-like systems. Under Windows there must be some tool, but I can't help you there.

---------


I have a few more things that bugged me while testing and I'll just note them down for reference before I forget them:

* First of all, related to the above: It's trivial to make KSM write to Nickel's config. To me it's important to be able to switch my device on in the night and for that I need brightness=1. We could have a feature that forces Nickel conf to be at least 1. For reference here's how I get and set the brightness value from the shell:

grep '^FrontLightLevel=' '/mnt/onboard/.kobo/Kobo/Kobo eReader.conf' | cut -d= -f2 | tr -d '\n'

brightness="$1"

if [ "$brightness" -ge 0 -a "$brightness" -le 100 ]; then
    sed -i -r 's/^(FrontLightLevel=)[0-9]+/\1'$brightness'/' '/mnt/onboard/.kobo/Kobo/Kobo eReader.conf'
else
    exit 1
fi

* It would be nice to have these two by default in `ksm_ini_options.txt`'s [general]:

ksmAutoselectoption=start_nickel_koreader_switch
ksmAutoselectoption=start_koreader_nickel_switch

* The "Info: Wifi is enabled!" message when returning to KSM is useful, but you still need to go into the wifi settings to switch it off. If it was a dialog with options "Switch it off"/"Leave it on" it would be even more useful.

* I use usbnet a lot and it would be heavenly if there was another way to change the desired IP address from the default 192.168.2.101 to something else from a configuration file / interactively instead of editing the script itself (I'm already on a 192.168.2.* network). This is probably a little too specific to developers.

* When the bouncer is vertical the keyboard is huge on my Kobo Glo HD.

* The bouncer can be vastly improved for security, including file security when the device is stolen. Since there is an `openssl` binary we can use that to decrypt encrypted files on boot, while at the same time verifying the password. This would have to be tweakable by the user somehow but I haven't worked on it at all. (Keep in mind that decrypting large files on these readers is slow, but if you're carrying work with you this can be very useful.)