MobileRead Forums - View Single Post - Kute File Monitor: A smarter file-trigger based launcher

NiLuJe · 06-11-2018, 09:25 AM

@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]).

06-11-2018, 09:25 AM	#65
NiLuJe BLAM! Posts: 13,477 Karma: 26012492 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@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]). Last edited by NiLuJe; 06-11-2018 at 10:26 AM.