* We no longer have a separate editing and browsing view - This does
mean we loose the ability to quick flip between notes by swiping.
However, this is more how a note editor would behave. I do later want to
add that capability back.
* We have 2 editors for now - Markdown and Raw. By default we use the
Markdown editor which can be toggled between Preview / Edit mode.
I later want to add a rich text editor and a todo editor as well.
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.
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.
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.
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.
When configuring the Git Repo server, we could optionally track one folder
in the root git repo, instead of just the root folder. This was
specifically to address my use case where I have my journals in a
sub-directory. The setup screen was super ugly, though.
Since now I'm in the process of adding folder support because of #18, I
can remove this hack. It simplifies the code a lot.
With this, the application compiles again. And note editing is working
again. This is was the first of some small refactors in order to
implement both async note loading and a support for directories.
It's time to start using a proper logger so we can control the number of
log messages, also - it helps to have a central configuration point for
the logs, specially since I would like to hook them up to Crashlytics in
the future.
For now I've mostly tried to follow the same style guide as the flutter
repository, with many options disabled. Eventually, maybe it would make
sense to be far stricter.
For now just create a local git repo and commit all the changes over
there, we're going to allow the user to first see the app and use it
however they want, and later connect it to a remote git repo.
This commit breaks the app, as the on-boarding screen is no longer
connected so you cannot push to a remote app.
It all just makes far more since when each Note has a fileName.
Though we don't save the fileName in the YAML header. It seems quite
redundant to do that.
Another advantage of this is that if we can read any file ending with a
'.md' in a git repo. It doesn't need to be named exactly how we want it,
and we will still save the details correctly.
