If that title already exists add an _Num at the end.
This won't change the default for existing users, as our settings system
saves the default value and will just load it the next time. This really
needs to be improved.
Some people are using GitJournal to edit Hugo websites, this option is
for them as the Hugo front matter uses the 'lastmod' key to indicate
when the post was last modified.
Possible Options - modified, mod, lastModified, lastMod, lastmodified or
lastmod. When read the the note we will figure out which one is being
used and accordingly write back that value.
This makes it easier to use GitJournal for editing Hugo websites as they
usually use the 'lastmod' field to indicate when the post was last modified.
This is so that we can start configuring what the yaml metadata keys
should be called, and not have them hardcoded.
This also allows the note.created to be null. Earlier we were always
setting it to some value. That's doesn't seem right.
Otherwise people can put # or : or something else in the title and that
will result in invalid YAML.
Also escape any existing '. YAML is weird that the method of escaping a
' is by specifying it twice. It's sad that there is no dart YAML
serializer, and I'm surely missing some other edge cases. The YAML
specification is quite long.
It's no longer a simple JournalListing and instead we also show the
title. The main problem is with what to do when the title is not there.
Just leaving it blank seems to feel weird, specially when the note is
too small.
Maybe it's time to change it such that each row size is not the same.
We're effectively wasting whitespace right now for very small notes.
We're moving away from being a Journal Editor to being a Note Editor. I
don't want to discard the Journaling parts, as Journaling is really a
subset of Note Taking - so in the future it would be nice if this could
be somehow toggled.
Maybe each Folder can have different display settings. Probably in the
"pro" version.
This somewhat shows what's going on with the network. It isn't ideal, as
is a bit ugly. But it's a start to show the network status, and what's
going on in the background.
We now have a much clearer separation between Git code and this app
specific code. This is awesome, it will allow other people to easily
integrate Git within their apps. Also, eventually it will be trivial to
switch to another implemention of Git (via JGit or a git client written
completely in Dart)
This breaks the iOS version as I haven't moved the code to build the ios
version. Maybe this will be a good excuse for me to setup a proper CI/CD
system for ios builds.
There is also a chance this breaks Crashalytics NDK symbols :(
The Git Api was strange and took a foldeName and it would only allow you
to access git operations in a particular path. This has now been fixed,
and now it can operate in any path.
This was the first step to moving the git api into its own library.
For safety we're only allowing non-empty folders to be deleted. Ideally,
we should have some kind of undo button. Or some kind of history - since
we do have that with git.
Related to #18
It's a bit confusing that the created date has to be set when creating a
new note, and the path had to be constructured properly, without which
the note shouldn't be saved. Ideally, an object shouldn't be able exist
in such an inconsistent state.
We aren't using it, and if we implement a recursive option it should
somehow showcase which folder it is under. Evernote does it in an
interesting way.
Also sort the notes based on when last modified. Now that we're moving
towards being a more note-taking app, it makes sense that a recently
modified note goes on top.
Of course, the sorting should be controllable by the user, but the
default probably should be by when modified.
Also make sure the _entities and _entityMap are always in sync.
The NotesFolder is complex enough that it could really use some proper
unit testing. Though since it is so tightly coupled to the FileSystem,
it would be quite an elaborate test to write.
Earlier whenever anything changed we would discard all the Notes +
NotesFolders in memory, and reconstruct the hierarchy. This would means
Notes which haven't changed at all, still need to parsed all over again.
Now we only reload what has actually changed.
This should result in a huge performance boost.
We still shouldn't be loading everything on boot, but that's a different
problem.
A NotesFolder doesn't only change when a note/folder is added or
removed. It is also changed when the contents of the Notes/Folders it
contains have changed.
This is a huge change which involves -
* Implementing Folder renames on the FS + Git level
* Implementing the concept of selecting an item in the FoldersListView,
this feature isn't provided by default, and even now I'm not sure if
the semantics which I've implemented are correct. I haven't
implemented multiple folder selection for now.
Related to issue #18
Also, we're now one step closer to allowing notes to be renamed (#23)
Folders for now can only be created under the root folder. I cannot seem
to figure out how to design a good interface for designing how to choose
the parent folder.
Now when adding/editing/removing a note, it gets modified from the
directory it was present in. There is no longer a just a plain list of
all notes, but always a tree of notes, which are inside Folders.
