Forum Archive

I have a feature request. If there is a formal location to provide please let me know so I can see if it's a dupe. I switch between files a lot and open editor to various content. Switching in general is laborious but at least there have been extensions to the framework the community has done. What I find annoying is if I open a file, say a .pyui file, and make an unwanted but unknown change, the change is saved on changing to another file, whether that is my intention or not. It's frustrating opening another's .pyui file to learn from it, then accidentally corrupting it. I would like a global option to say ask to save or not or a different mechanism to close current file. What do you think?

A similar idea may be the option to open a file in read-only or preview mode so unintentional edits are not saved. If there is this capability I didn't know it.

I can't see myself implementing an explicit save dialog – that's just not the way it's done on iOS, and for good reasons. Diverting from the common pattern would make it more likely that users accidentally discard changes because a save dialog is just not something you expect on iOS (and it violates the Apple design guidelines which can actually be a reason for being rejected in review).

That said though, I definitely see your point, and it's an absolutely valid concern. I can see several ways in which I could address this. For one thing, it would probably be a good idea if the UI editor had some basic undo support. That's definitely on my todo list, but because I didn't really think of this at the beginning, it's not completely trivial to implement (e.g. coalescing changes, so you don't have an undo step for every pixel when you move an object...).

More broadly, something I'd really like to do would be to have some kind of simple versioning system. I'm not really thinking of integrating full-blown git support or anything like that (to make that actually useful, i.e. work with remote repositories would break Apple's rules, and frankly, I also find git a bit too complicated for beginners) – but having some sort of semi-automatic "snapshot" system would be very useful, I think. I imagine that this would automatically create snapshots for every auto-save, and you could add your own "milestone" snapshots with a title or comment (for known "good states" etc.)... I haven't really started working on this, and there's probably a lot of new UI that I'd need for viewing diffs etc., so please don't expect anything like it in the very near future, but rest assured that it's a problem I'm aware of.

One possibility that would be simple to implement is to help automate the creation of a ZIP archive, create a timestamp and then do "adds" to it whenever a file has changed. Many of us are already using something like this to backup all our stuff and then sending the archive to DropBox. What is currently missing is automation and the "restore" part. Getting the archive back from DropBox and scripts allowing you to unzip the archive based on a timestamps or folders specs would be nice to have. Automation of when to run the archive process and to only archive the deltas would be really nice.

Some basic support from the Pythonista App to automate such a process is what is really required. The ability to run a script in the background whenever certain "events" occur like file updates, startup, shutdown. Some UI would be needed to show the list of events and trigger rollbacks. Maybe use the ZIP file model as the out of the box method but leave it up to the community to support other backup/restore methods like git, etc.

Come to think of it, this same type of thing would support another highly desirable feature. This is "indexing" of the content in your document tree. I mean - like full text indexing - so that you could search for files based on keywords. The same kind of infrastructure is required to keep an index updated. Something has to trigger change events as they occur in order to keep the process efficient.

I like the idea of a persistent undo system, but I'm not sure how it would really work. If it was just an extension of the iOS undo available from the keyboard (basically saving off the undo history when files are saved, and loading it again when files are loaded), that seems ok. But files can be modified outside of the editor, so those cases would have to be handled.

If instead the whole file was saved, I.e. Save the last N versions, you'd have to decide what constitutes a version... Each edit, or only when file was switched, etc.

@JonB - I would like to know more about when all the "file save" events happen right now. I believe that an App is constantly forced to save state as the user causes context switches and such. Pythonista could also add a configurable "auto save" that does a save if the use has not done any text input for a certain amount of time. Maybe it already does this. My concern would be that creating too many deltas would eat up storage space quickly.

I hate the auto save feature. too much accidental change. and the undo system often doesn't work

Read the whole thread and my $.02 ...

Auto save is a must on iOS device and I don't see a reason why this should be changed (as Ole explained, divert from default iOS behaviour).

Let's focus on the root issue. @ltddev opens file, accidentally modifies it and the file is saved. What can be done with this? Editors usually use * (or any other way) to tell the user (visually) that the file was modified. It's useless when there's auto save. But what if the same concept is reused, in a slightly different way:

• Open file
• Remember file revision (content)
• If edit was made, show * (or something else) even if the file was auto saved
• Allow to revert to the state in which the file was when I did open it for the first time

In other words, use the same concept with *, but not for individual edits between saves, but when open time revision differs from current file state.

Also allow me to close it without any warning, dialog, ... Just not to change current behaviour. In this way, you can be visually informed that you made some changes and you can explicitly revert the file content.

@zrzka I like that idea.

it'd be good if revert is possible.

my trick is to add os.chmod to editor's action wrench menu.
after change file mode to readonly, there's no danger of accidental keyin possible. the keyboard doesn't show at all now.