Kute File Monitor: A smarter file-trigger based launcher

[tshering]

I just noted a discussion on github koreader. I am a little in a hurry now and cannot check exactly, but I guess kfmon is started from on-animator.sh. Right? If this is the case, KSM does prevent it from beeing started. It does this by bypassing on-animator.sh. The reason was to prevent kobolauncher's fmon to be started from the user partition.

[NiLuJe]

@tshering: You're perfectly right, I misread the rcS diff (I, err, skipped over that 'exit' there ).

That's the correct behavior, BTW, we don't want any of them to step on each other's toes .

That's one more reason I'm glad I went back to using on-animator vs. the udev rule trick .

[NiLuJe]

Okay, I've spent the last few days working on a small tool/library to print messages on screen, and I think I've finally got it in a decent state .

So, here's a prerelease version of KFMon v1.1.0, which integrates this library to shout at you when things go wrong .

EDIT: This is part of the 1.2.0 release .

----

A few things of note for the technically inclined: my H2O is up to date, so it's post-32bpp switch. 16bpp support should be mostly sane, with the caveat that the colors *might* be inverted (i.e., white on black, while the default should be black and white).
If you happen to run a device still running a 16bpp FW, I'd be glad to know how it fares there .

Also, there's no real rotation handling, it's expecting 0,0 to be the top-left of the screen. It holds true on my H2O on FW 4.8 (... once Nickel has finished booting), and on every Kindle I've got.
That probably won't change, because I nearly broke my brain with basic geometry working on this already, but, still, for science! it'd be interesting to know if weird crap happens on that front on other setups.
(And before you try KOReader in landscape mode: nope, it's a software viewport rotation).

If you're familiar with Kindles, you'll note that eips makes no effort on that front either .

[datanoise]

Hi

Nice job, thanks!

Would it be possible to create a rule with a wilcard, so that we can automatically open PDF files with koreader (for example), like it's possible on the kindle?

It seems to me that's it's not possible yet; that would be an awesome feature. If that's not possible, do you think it's going to become possible in the future?

[NiLuJe]

@datanoise: While technically possible, this isn't what this was designed for.

I'm expecting a strict one icon -> one specific script matching, and said script is hardcoded in the config file, I'm not building it dynamically.

What you suggest would mean, first: a mass setting of inotify watches, which is problematic for a whole other reason, but, okay; and then, honor a per-file-extension/per-mimetype action instead, and dynamically building the command following that (i.e. pickup simply the path to koreader.sh from the config, and dynamically appending the <filename> to it).

TL;DR: That's a *significant* design difference, so, probably not going to happen, especially for a feature I won't use .

EDIT: To expand a bit on the difference w/ a Kindle: on a Kindle, we essentially just ask the system to open this mimetype with this app, and that's it, it does all the grunt work for us .
On Kobo, we can't tell the system anything, and it doesn't tell us anything either (because if there was simply a way to get passed *everything* Nickel opens and then parse that and do what needs to be done, that'd be enough to solve all our problems). So here, I'm essentially forced to go as low as one can go: I'm asking the Linux *kernel* what's happening to a set of *specific* files.
Doing that on a large number of files is already iffy enough on desktop machines, doing it here would be plain murder: besides the inotify thing, I'd have to begin by walking the whole directory tree *at boot*, picking the right files one by one... I don't know if you've noticed, but the storage is painfully, painfully slow on these things .

So, yes, while theoretically possible, in practice I feel like that'd be a fairly terrible idea, even if it had fit into KFMon's design .

EDIT²: Random thought after writing that: monkey patching Nickel to overload whatever its OpenThisDocument call is? Out of my depth, and potentially fragile, but, hey, fun times for a C++ guy ;p.

EDIT^3: Random thought bis: might be able to pull the last opened book from the db, there's a sort by date, after all . That's missing the right trigger for knowing *when* to do that, though. (That's essentially how the cover mode of the ScreenSavers hack works on Kindle, because I *have* an event "a book was opened" to listen to to tell me it's safe to check the db knowing that it'll be up to date [well, mostly, see my "storage is slow" argument, I have to delay for a few seconds to be sure of that]).

[datanoise]

Thanks for your detailed answer.

Sounds like it totally makes sense to keep it that way. Sad that kobo doesn't makes it more easy to integrate third party reading apps for specific mimetypes.

A script launched when the storage is unmounted could maybe add the needed paths to the database, making it possible to parse that list from the db, avoiding the need to walk the whole directory tree at boot. But anyway relying on inotify for too many files seems problematic, there's probably no way this could scale to more than a few books without big downsides...

Edit: not related to KFM but wouldn't it be possible to trick nickel replacing the original pdf reader with a wrapper that would start koreader? Might be totally stupid, I need to find a kobo on which to experiment stuff and understand better how nickel works.

[NiLuJe]

@datanoise: Nickel is monolithic (it's basically a single Qt app, and a main libnickel library). Everything *is* Nickel.

(In practice, it's slightly less cut and dry than that, ePub handling w/ Adobe DRM gets slightly trickier, and some Extras functionality live in separate libraries (i.e., games), but basically, everything ends up running from Nickel the app *and* nickel the binary ).

Which, AFAICT, limits possible interaction with it to monkey patching or preload trickery (c.f., nightmode, whose job is "easy", because it intercepts a public API with public data: an ioctl talking to the mxcfb kernel driver. ioctl is a standard Linux API, and the relevant mxcfb headers are (mostly) public, so we know how to format/decode the data)).

[datanoise]

Patching would probably be the way to go to automatically open koreader to read PDFs.

Started looking into libnickel. They didn't make it easy to customise their ereader. Funny that amazon kindle is easier to adapt to your needs, once jailbroken...

[NiLuJe]

Note that by monkey patching, I do mean that: runtime patching of running code (although I forget what the proper term is in C/C++ land, but basically, dlopen/dlsym, function hooking & co).

Not to be confused with the "offline" binary patches we all know and love over here .

[datanoise]

Ok, thanks for that clarification

[NiLuJe]

Updated #63 with a new build, pulling the latest FBInk changes (which should, hopefully, not cause any regression nor new bugs ).

[datanoise]

Finally found a used H2o2 (version 2), kfm works very nicely, and koreader as well with your last device.lua. Thank you very much!

edit: mistake: kfm, not ksm (didn't try)

[NiLuJe]

@datanoise: Fantastic, thanks for confirming that it behaves properly .

[tshering]

CH23 has uploaded the output of depmod.

[tshering]

Originally Posted by datanoise

Finally found a used H2o2 (version 2), ksm works very nicely, and koreader as well with your last device.lua. Thank you very much!

Are you sure that you have got a H2o2v2? This is a rather recent model. If you have one, what did you do to make KSM work? Did your replace the touch driver with the newest version? Anything else? Or did you mean KFMon?