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

Aggressive caching of proofing formats in Electron #566

Open
mcdemarco opened this issue Jun 25, 2019 · 6 comments
Open

Aggressive caching of proofing formats in Electron #566

mcdemarco opened this issue Jun 25, 2019 · 6 comments

Comments

@mcdemarco
Copy link

@mcdemarco mcdemarco commented Jun 25, 2019

I updated the version of one of my proofing formats from 1.1.0 to 1.1.1. The change was reflected immediately in the online twine at the Twinery, but due to issue #563 I couldn't test there so I was testing in a download of 2.3.1 (Mac OS). The format never updated automagically, and even when I deleted and re-added it, the old format # appeared, not the new one.

I tried 2.3.2 after that to see if the problem was fixed, but had the same issue of the old version being cached. Note, I also had to close and reopen Twine to get a deleted story format to leave the list; if I added it without doing that I'd get two copies in the list. (Their button states remained amusingly in sync with each other.)

I should mention that this wasn't a superficial numbering issue; the bug fix from the updated story format was not present, either.

I read a bit about unwanted Electron caching, including some SO advice about how to clear the cache programmatically, but I didn't find a manual workaround for the problem.

@klembot
Copy link
Owner

@klembot klembot commented Aug 12, 2019

It seems plausible that this might be fixable by clearing cache upon opening a story for editing... the downside would be, if you lost your network connection between when you opened Twine and when you started editing, you'd be stuck. We could add a manual refresh button to the story format dialog, but that feels annoying to put the onus on the user.

Of course, the other workaround is to have unique URLs for each version. But that's annoying and possibly unwanted behavior, especially if you're doing just bugfixes and you want people to get them without having to fiddle with settings.

@StoltHD
Copy link

@StoltHD StoltHD commented Jul 24, 2020

This is still a problem and is also a problem with Twine 2 (v.2.3.9) Desktop on Windows 10 Enterprise N (Insider version) ...
I had a lot of problems with upgrading, as I described in the issue that mcdemarco link to, I had to reinstall multiple times, and even tried to delete some of the files that was referenced in the Developer Panel, but with no luck ... I still don't know what it was that solved the problem ... the reinstall and multiple try of adding the format, or something else ...

I also have another problem there most likely for the same reason and that is that I have 2 tumbnails to 2 Stories with different dates, but same name and when I open them, both open the same Story ... it do not help to delete one or both and reimport, after the first time I open the story with any of the tumbnails, the second comes back, with the old date ...

@HiEv
Copy link
Contributor

@HiEv HiEv commented Aug 2, 2020

I also have another problem there most likely for the same reason and that is that I have 2 tumbnails to 2 Stories with different dates, but same name and when I open them, both open the same Story ... it do not help to delete one or both and reimport, after the first time I open the story with any of the tumbnails, the second comes back, with the old date ...

@StoltHD - This was due to a bug which has mostly been fixed in Twine v2.3.9, however your data within Twine is currently corrupt, even if you've updated.

To fix that, follow the instructions here, and then Twine should work properly again.

Note: If you import a file which has the same name as a file which is already in Twine, you must rename it in v2.3.9 or you risk running into the same problem.

Hope that helps! 😀

@StoltHD
Copy link

@StoltHD StoltHD commented Aug 3, 2020

@HiEv
Copy link
Contributor

@HiEv HiEv commented Aug 5, 2020

The breaks are done the same way as in this example in the Graphviz Gallery...
https://graphviz.org/Gallery/directed/kennedyanc.html

I'm sorry, I have no idea what that has to do with the problem I replied to you on or the fix I suggested. Especially since this is the first time you've mentioned "breaks" anywhere in this issue report.

Did you perhaps respond to the wrong issue or something?

@StoltHD
Copy link

@StoltHD StoltHD commented Aug 5, 2020

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

Successfully merging a pull request may close this issue.

None yet
4 participants