Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KOSync: Clarify settings, plus refactor & fixes to make "auto-sync" more reliable #10605

Merged
merged 74 commits into from Jul 2, 2023

Conversation

NiLuJe
Copy link
Member

@NiLuJe NiLuJe commented Jun 23, 2023

Fix: #10539, and for context #6489, #6733, #6534

Reorganize and reword most of the settings to make it clear what actually ties into auto sync, and what doesn't. (Specifically, what happens when a pull attempts to sync forward or backward has nothing to do with auto sync, it applies in all cases; while the periodic sync does require auto sync).

The main point of contention, though, is that auto sync will now always attempt to setup network connectivity (i.e., on resume/suspend/close). Periodic sync will not though (the intent being that, if you use periodic sync, you're relying on the activity check to actually keep wifi on at all times)).

Since this may lead to a large amount of nagging about wifi toggles on devices w/ NetworkManager support, it is now disabled by default on those devices. (And given that it wouldn't have worked because of the lack of connectivity, that doesn't really make any practical difference ;p).

Additionally, given the fact that there's no way to make this behavior viable if the "before wifi" action is left at its default of "prompt", this feature now requires that to be set to "turn_on" (on devices where it can, of course); attempting to toggle it on will warn about that if necessary.
This change is retroactive (OTM).

Includes an assortment of fixes and cleanups, including migrating to the new LuaSettings API, which is why there's no longer a smattering of superfluous flushes.

RFC, because I don't actually use the plugin.


This change is Reviewable

@NiLuJe
Copy link
Member Author

NiLuJe commented Jun 23, 2023

Note to potential testers: please follow #10603, as the official sync server will be down for a few days ;).

@Frenzie Frenzie added this to the 2023.07 milestone Jun 23, 2023
NiLuJe added 11 commits June 26, 2023 17:27
Also, tie "Sync every # pages" with auto sync, as it requires it.
As it's going to be naggy as hell once I'm done with it

Also, until sync behavior from autosync, as it has nothing to do with
it,; it's the sync behavior, *period*, manual syncs included.
Note that with a periodic sync often enough, it might be enough to
overcome the network activity check, and leave WiFi enabled at all
times...
(I, err, had completely forgotten that I'd even started to implement it
at all...).
You've obviously got bigger issues than this is there's no top-level
visible widget, though ;p.
Prevents running it again right away after an extended skim ;).
Copy link
Member Author

@NiLuJe NiLuJe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 5 of 7 files at r1, 3 of 5 files at r2, 3 of 3 files at r3, 2 of 2 files at r4, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @NiLuJe)

@NiLuJe
Copy link
Member Author

NiLuJe commented Jul 2, 2023

onCloseDocument

The whole lifecycle stuff actually precludes any sort of async shenanigans without a lot more consideration, in fact.

  • This is not core, it's a plugin, so the plugin's instance will be torn down onCloseWidget (which will come very soon after onCloseDocument).
  • We lose the document instance after onCloseDocument returns, and we need bits of it. That could be sortof handled by pulling the data now, and caching it somewhere in our instance, and then using that in the sync call.
  • But the actual plugin instance will die very soon after that, so you're back at square one anyway ;o).

(I mean, GC magic should handle some of the "zombie" stuff properly, but I'd be extremely, extremely wary of it, and it would look and feel super confusing, code-wise. (And set a precedent I strongly object to.)).

TL;DR: This is probably the best it's ever going to be, and it's quite likely broken as hell with turbo enabled anyway ^^.

@NiLuJe NiLuJe changed the title KOSync: Clarify settings to make the "auto sync" mode tradeoffs clearer KOSync: Clarify settings, plus refactor & fixes to make "auto-sync" more reliable Jul 2, 2023
i.e., chekc that we actually have *some* settings from that plugin,
instead of force-feeding the defaults no matter what.

(That'll happen on plugin load anyway ;p).
(I went low mostly to ease testing)
Copy link
Member Author

@NiLuJe NiLuJe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 2 of 2 files at r5, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @NiLuJe)

@NiLuJe NiLuJe merged commit 08dd973 into koreader:master Jul 2, 2023
4 checks passed
@Frenzie Frenzie added the Plugin label Jul 3, 2023
@Frenzie Frenzie modified the milestones: 2023.07, 2023.06.1 Jul 4, 2023

function KOSync:getSyncPeriod()
if not self.settings.auto_sync then
return _("Unavailable")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably better to use "Not available" (which is already translated), unless there's a specific reason to use unavailable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not particularly, no ;).

@hius07
Copy link
Member

hius07 commented Jul 9, 2023

Current behaviour: I am in a book, have "Automatically keep documents in sync" checked, wifi off.
I want to exit to the file browser, make a gesture - nothing is happenning during 30 seconds, then I see the file browser with confirmbox "Do you want to turn on wi-fi?".
So, the issue - the confirmbox doesn't show up over the reader.

@NiLuJe
Copy link
Member Author

NiLuJe commented Jul 9, 2023

That's most likely gesture-specific (possibly we're missing an UI frame for the popup to actually show up), because this works via the Menu ;).

I'll look into it, thanks!

@NiLuJe
Copy link
Member Author

NiLuJe commented Jul 9, 2023

Err, wait, never mind, this should not work with "prompt" as the before wifi action, which getting a "Do you want to turn on wi-fi?" implies it's what it is set to?

Unless you switched to prompt from inside a document, auto sync should have been disabled on document load in that case, so, I'm confused.

(There may be Kindle-specific shenanigans involved, as I'm not entirely sure you actually have the choice of before wifi action on there...).

@hius07
Copy link
Member

hius07 commented Jul 9, 2023

That's most likely gesture-specific

The same when leaving the reader via the upper menu "file browser" icon.

you actually have the choice of before wifi action on there

No, we do not have it on Kindle.

@hius07
Copy link
Member

hius07 commented Jul 9, 2023

So after 30 s timeout the reader is closed, and in the file browser:

1

@NiLuJe
Copy link
Member Author

NiLuJe commented Jul 9, 2023

Oh, yeah, I was living in a happy dreamland where everything not Android was hasWifiManager. This... isn't the case ;o).

(And Kindle isn't even hasWifiToggle for... some reason?). (it's on by default ;p)

I'll see if I can fudge before_wifi support on those platforms, because prompt will never ever work for this use-case (we'd need UI frames to tick, while also delaying event propagation to stop one in its track in its own handler. That's just plain not possible).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Progress Sync does not automatically push/pull on Kobo Sage
3 participants