Is anyone using this latest preview (326) to sync across Dropbox? I’ve had reports that it’s not working, but in my testing it does seem to be working. So looking for more input… is dropbox sync working for you?
Odd… I don’t think that I’ve changed anything in that part of the code, and it seems to be working for me. Can you try again, what happens if you try to create a new saved search in TaskPaper 3.8… right click in searches section of sidebar and choose “New Search” from the popup menu. Does that search show up? Is it restored next time you restart the application?
Is anyone else seeing this problem?
I just tested it. I did experience it initially. But on the second, third and fourth tries, sync was working as expected.
Using Editorial on iOS, TaskPaper (326) and Dropbox v56.4.94
1 Like
I’m a little confused as to how a Dropbox sync problem would manifest itself. Is it that Dropbox fails to recognize that a TaskPaper file has been updated?
Purely a speculative guess: Maybe this build of TaskPaper doesn’t set the modification date correctly?
Yes, I “think” that’s what the problem is… make a change on one document and the change doesn’t show up in other document. But as I said, for me it seems to work. The sticking points that I can think of are:
-
For the sync to start the document needs to actually be saved. This can be via autosave, or with a manual save. One issue might be that autosave isn’t getting triggered as soon as people expect. If you switch away from TaskPaper then it should autosave right away, but if you edit a document… and don’t switch away from Taskpaper, and don’t explicitly save then autosave can take longer.
-
The other issue is that noticing that a file has changed wasn’t working (in 3.8) until release 326. So if you are on an older beta it likely won’t work.
I guess anything is possible, but I don’t think that would be it. The code that sets modification dates and such is all in the system frameworks, not something that I’m directly programming. And even so I haven’t changed any of my document saving code that I can’t think of.
The autosave possibility does make more sense.
Since I can’t reliably reproduce it, I am giving up for now.
Hi Jesse, I have installed the final 3.8 version here and I’m still having this strange issue with default searches and tags that are stored inside the /Users/~/Library/Application Support/TaskPaper/Configurations
The 3.7.7 read them with no problem and 3.8 won’t read a thing.
I’ve tried so save a search in 3.8. I can save it and it appears in the Searches sidebar menu but when I quit and relaunch TaskPaper, it won’t be saved and the menu is blank…again.
Maybe it’s some sort of permissions problem… can you try:
- Quit TaskPaper
- Remove (move to desktop so you can recover styles/etc if you want) ~/Library/Application Support/TaskPaper
- Restart TaskPaper
And then see if you create searches in the sidebar and have them save.
I’ve just tested this again and for me at least this is working in the lastest TaskPaper on both macOS 10.13 and 10.14. Hopefully a rebuild of TaskPaper’s Application Support folder will do it. If that doesn’t work, can you try from guest user account and see if searches are persistent there?
Nope. This is not working.
TP 3.8 is able to read the Styles but not the configurations??
Something has changed for sure??
Thanks.
I agree something must have changed… but I’m have a hard time figuring out what might be wrong. Do you see anything that might be related in Console.app? Maybe email me directly (jesse@hogbaysoftware.com) if it’s OK with you I could try remote login to your computer and see if I can debug things a bit further that way.
Any news about that?
Sorry, nothing new. I still can’t reproduce.
Did you see my earlier post:
Thanks Jesse, lags are gone in 3.8.2 preview and my tags are back!! This is indeed really nice!
1 Like