Fixes#972
This required regenerating the protobufs generated files, which seem to
have tons of extra changes, and needed some manual changes to get them
to compile.
Overall, the entire protobuf idea wasn't the best in retrospect, and in
the next version of GitJournal, I'll be going with a simple relational
database instead.
Instead we're going to move back to standard exceptions.
Using a custom Result class has created far far more problems
- The Stacktraces aren't always right
- Sometimes one forgets to check the Result error
- All other exception throwing code needing to be converted to Results
- Non idiomatic Dart code
I think it's better to just go back to exceptions. They have their
problems, but overall, I think it's a better approach.
I'm trying to get ride of this huge 'Note' class, and have it be quite
dumb. The idea is that we'll have separate Note subclasses - TxtNote,
MdNote, etc
It's not ideal as the hash is now calculated twice, but it simplifies
such a large porition of the code as I can put proper asserts to make
sure all Files in the NotesFolderFS always have a valid GitHash.
This greatly simplifies the entire data flow. Though, it comes at the
risk of introducing bugs, but I think it's worth it.
Plus, it makes everything far far more testable.
Certain Editors only support certain file formats. We can create an
editor either by -
* Giving it a Note, and letting it choose an editor based on the default
/ note metadata
* New Note with a file type
* New Note with a editor type + possible file type
Fixes#78
This is probably the largest commit that I have ever made. From now on -
every File always has an mtime and ctime which is fetched from git.
Notes can optionally override that time by providing yaml metadata.
Additionally the 'filePath' and 'folderPath' is now relative to the
repoPath instead of being the full path.
This will slow down GitJournal like crazy as all the mtimes and ctime
still need to be cached. For my test repo it takes about 23 seconds for
GitJournal to become responsive.
Instead there is a new type called 'UnopenedFile'. This was part of my
effort to not have everything inside the 'Note' class and to make it a
bit more immutable.
But, wow, this took a very long time. The 'Note' class seems to be very
deeply integrated everywhere.
This makes us one step closer to making the Note class immutable which
will help GitJournal's overall architecture a lot. Plus it makes me one
step closer to having proper web support.
I'm trying to move all FS related operations out of the Note class, and
ideally make it super small. This class will need to be serialized over
the wire for the web version, and that needs it to be small.
Platform from dart:io cannot be used on the web for reasons. And this
way we get a fake File/Directory class which we can use for atleast
running the web version, even if it won't work.
Stop it being a singleton. This means it needs to be passed around a
lot. This sucks, but it's how it should be. I shouldn't be using a
global variable to get around this.
This is needed as Settings will soon become repo specific when we
support multiple repos.
This breaks saving the settings in a file, that feature was toggled off
anyway. It needs to be thought over again.
We were mixing up header links with wiki links and the alt text. It was
a bit messy. We currently do not support linking to a particular part of
a note. Nor do we support wiki links as link references.
Fixes APP-A0
This reverts commit 303192d9d575b26a77a00f7a62212f310ec1e329.
This reverts commit cd9d128b47ed523036f7ae1232ec7adcf04ed8a9.
GitJournal is used by non-English speakers (a lot in China and Russia)
and while we don't support those languages completely, we do support
them a little bit. I don't want to loose this functionality. It would be
better for us to fix the bug in intl.
