@Briarfox: to maintain the tab order, could you perhaps include the project’s info.plist to the gist, and then when downloading the project from gist to Codea, read the tab order back out of the info.plist without actually saving the plist back to the project?
Then, it’s just a matter of a downloading and saving the tabs in the specified order. I ported jQuery’s Deferred to Lua awhile back, it’s ideal for doing just such a thing very easily. If you’d like I could post an example of how to do it.
@Andrew_Stacey I’m trying to come up with a fix for the time out. My attempt at sending each tab separately results in a revision for each tab. I’m trying to figure out whats causing the time out becuase all tabs seem to be received by github. From my research it appears to be on githubs end but I’m not to sure. Any ideas?
Now that I’m using toadkick’s cmodule stuff then I’m going to split my Library into separate projects which will make it smaller and so more amenable to using AutoGist.
It’s an example of downloading the Info.plist from my sprite batch tab example on github, and then creating a download chain from the projects in the “Buffer Order” table, saving as tabs upon successful retrieval.
Need some advice guys. I’m moving the data storage to a table. Should I store the version info locally in a table and single save? This would store all versions and revision keys. This would allow you to plug in an older version and pull it from gist. Or should every project be saved in AutoGists Global table? This is only for the version tracking. The PullManager will store all the gists you pulled down and let you know if an update is available
@Briarfox One issue I worry about with storing the data locally is that it can conflict with someone wanting to clear the local data in their project. So I would go for storing everything in AutoGist’s global table (and even make AutoGist back it up into its own local table whenever it runs).
How would you best use AutoGist in this scenario: 3 people are working on a single Codea project, each working on separate tabs. Two are using Codea on iPads, one is typing code on a PC.
My solution was to have 3 copies of the project in 3 gists and having the PC user propagating changes between the 3 gists to synchronise all 3. Very messy.
@inoddy yeah it would be pretty messy. Only way I can think of is get in the habit of pulling the gist, then pushing it when done. But that would only work if you are working on separate tabs. After I get AutoGist to where I want to take it, I’d like to rework the github client for codea. That would suit your needs much better.
Thanks @Andrew_Stacey very helpful. I’m still reworking the storage and decided to move AutoGist to a class. I’m still working on making sure all of the old data is transfered over so no gist id need to be put in manually.
-All data is now stored in a single Global save
-You can use whatever you want for version numbering ex: 1.12, 1.23.5678, 1.23alpha
-revision keys are now saved to each version number. This will allow downgrading versions in a future update.
2.083 fixes a small issue with the updater not working
@Briarfox Great! I’ve updated (amusingly, there was a small bug in the old update function: the project name and gist id were passed to the function the wrong way around.)
@Briarfox After updating then I had to reauthenticate with gist. Will I have to do that every update or was that a feature of changing the storage mechanism?
Hi Briarfox. Great work you are doing here.
I havent used the authentification stuff and, from what i’ve read in this thread, it seems not obvious the first time one does it. Have you, or do you plan to, include in your tool a small text tuto that describe step by step how to get that from the ipad? That would surely help people who are a bit afraid of getting lost there (like me) to take the step to autogist?
Anyway thanks again for your work!
after i posted i went and looked to see how far back it went.