Decouple edit and save buttons about mavo HOT 11 CLOSED

presumably history/undo is in the pipeline, at which point revert may be
less important

On 2/25/2016 9:59 PM, Lea Verou wrote:

Currently, pressing saves returns the user to read mode. However,
since editing is now global, it makes sense that the user would want
to save often, without necessarily concluding their editing.
Therefore, Edit should become a toggle between edit and read mode, and
save should do nothing more than save.

Then we can also move the saving progress indicator to the save
button, and maybe in the future have autosave.

The only wart is, now what does cancel do?
The easiest to implement option would be that it just discards any
unsaved changes. If they enabled autosave, well, tough luck. This is
probably what we'll do initially. And rename it to "Revert", obvs.

—
Reply to this email directly or view it on GitHub
https://github.com/LeaVerou/wysie/issues/39.

from mavo.

there's also the google docs model, which is that every operation is
persisted (unless there's a network failure etc.). There's no explicit
save. Then you navigate through history if you want to revert something.

On 2/25/2016 9:59 PM, Lea Verou wrote:

Currently, pressing saves returns the user to read mode. However,
since editing is now global, it makes sense that the user would want
to save often, without necessarily concluding their editing.
Therefore, Edit should become a toggle between edit and read mode, and
save should do nothing more than save.

Then we can also move the saving progress indicator to the save
button, and maybe in the future have autosave.

The only wart is, now what does cancel do?
The easiest to implement option would be that it just discards any
unsaved changes. If they enabled autosave, well, tough luck. This is
probably what we'll do initially. And rename it to "Revert", obvs.

—
Reply to this email directly or view it on GitHub
https://github.com/LeaVerou/wysie/issues/39.

from mavo.

Yes, it's in the pipeline :)

If the backend supports revisions (e.g. Dropbox, Github) we can even offer a UI for going through their history.

from mavo.

And if the back-end doesn't support revisions, we could store a
representation of the complete history (sequence of modification) in the
json file. Even if revisions are supported in theback end, we may get
more power with our own representation than when we rely on the back end.

On 2/25/2016 10:15 PM, Lea Verou wrote:

Yes, it's in the pipeline :)

If the backend supports revisions (e.g. Dropbox, Github) we can even
offer a UI for going through their history.

—
Reply to this email directly or view it on GitHub
https://github.com/LeaVerou/wysie/issues/39#issuecomment-189091490.

from mavo.

Why would we do that? If they want revisions, they can choose a backend that supports revisions. Reinventing that particular wheel ourselves seems neither interesting, nor fun. Unless you have some idea in mind about how we could do it better…

from mavo.

the advantage of doing it ourselves is that we know the semantics. we
can represent diffs in terms of additions, deletions, and edits of
fields, as opposed to changes in lines of a mysterious json file. Not
important for actually "checking out" a revision, but may be super
useful for comparing differences (and finding the particular revision
you want).

May not be hard to implement, using someone else's history library.

On 2/25/2016 10:28 PM, Lea Verou wrote:

Why would we do that? If they want revisions, they can choose a
backend that supports revisions. Reinventing that particular wheel
ourselves seems neither interesting, nor fun. Unless you have some
idea in mind about how we could do it better…

—
Reply to this email directly or view it on GitHub
https://github.com/LeaVerou/wysie/issues/39#issuecomment-189095722.

from mavo.

Probably easier to parse the diff than reimplement history.

Also, if we ever implement my "suggest edit" idea, we'd need to parse diffs anyway, to present the suggested edits (i.e. what would be a pull request behind the scenes).

from mavo.

parsing diffs will be messy and error prone, whereas recording each
change as we make it should be easy. and if we have that history
record, we can use it to build the suggested edits.

But, this is all in far future and not worth deciding now .

On 2/25/2016 10:38 PM, Lea Verou wrote:

Probably easier to parse the diff than reimplement history.

Also, if we ever implement my "suggest edit" idea, we'd need to parse
diffs anyway, to present the suggested edits (i.e. what would be a
pull request behind the scenes).

—
Reply to this email directly or view it on GitHub
https://github.com/LeaVerou/wysie/issues/39#issuecomment-189098339.

from mavo.

That will not work with pull requests, as we cannot update the main file.
We can of course save it as part of the pull request, but it gets really messy.

from mavo.

Actually, we don’t need to parse or store anything. If all we want is a visual indication of changes, we can just apply the new version of the file and highlight the properties that now have different values, in some kind of special mode.

from mavo.

very elegant!

On 2/25/2016 11:11 PM, Lea Verou wrote:

Actually, we don’t need to parse or store anything. If all we want is
a visual indication of changes, we can just apply the new version of
the file and highlight the properties that now have different values,
in some kind of special mode.

—
Reply to this email directly or view it on GitHub
https://github.com/LeaVerou/wysie/issues/39#issuecomment-189102863.

from mavo.