Failed to save reading progress and highlights
After opening an epub file, setting some highlights and then restart Plato, it will be gone.
Just found out that click "Quit" manually is needed, It's no problem now. But is it possible to save progress automatically? I use remux as launcher, it provide "kill" button, so click "quit" is a unnatural behavior.
I'll look into doing an autosave for this. I guess, for the Kobo, this is not a real issue, since using plato there would be more permanent afaik.
Wanted to fix a self-made bug I encountered today anyway (eraser side tapping twice, finger up == finger down?) in the next few days. So might as well fix this as well and make a new full release of it.
cc @baskerville
Maybe a quick and easy fix would be to add a "Save" option to the main menu. So one can decide saving explicitly. Maybe also as a selectable interval.
The reading states can already be manually saved with Database|Filesystem → Flush (in the library menu).
Properly solving the original problem would require changes in both Plato and remux:
-
Plato would need to handle
SIGTERM. -
remux would need to use
SIGTERMinstead ofSIGKILLwhen killing apps.
Didn't actually know about this option. That's nice to know.
And yeah, killing with remux isn't healthy for apps. While I really like the option to just get rid of apps, I kinda expected that it would just sigkill them since otherwise they might clutter up the screen (I know first hand that everything else doesn't work when SIGSTOP'ed since the app would run in order to react to other signals).
@raisjn The best case would probably be to be able to have remux do your proposed "nice killing" and have plato just handle SIGINT and/or SIGTERM which would be an easy fix. But this would complicate things more, make misbehaving possible as you said and would probably require some further meddling/alteration of the current draft launcher file format.
Proposed solution: How about remux sending to-be-paused apps a signal like USR1 and delay the pause for e.g. 100ms (or wait for the signal to be handled if possible). That way:
- plato could flush the database always right before pause
- a kill would not be a problem
- apps/launchers not using this behaviour should not affect anything
So it's a divergence on design, both Plato and remux are fine, no change should be taken from my perspective.
iiuc, you can mmap the save progress file into memory and writes to it will be persisted even if the process is killed
I didn't know about the aforementioned mmap behavior, thank you for the tip.
Proposed solution: How about remux sending to-be-paused apps a signal like USR1 and delay the pause for e.g. 100ms (or wait for the signal to be handled if possible). That way:
yeah, i can do something like this, i'll look into it. i think i'll give 100ms or so then send SIGKILL.