This changes the way the SSH keys are managed, they are no longer
managed by the git_bindings plugin and are instead just passed as
parameters. They are now saved in shared_prefs. This allows us to easily
have multiple ssh keys.
It also allows us to store the ssh keys in a more secure storage
location in the future.
We now infer this by checking if the directory exists, and by reading
the git config. It's a bit slower, but it's a far better method. I can
add a cache later, if it turns out to be too slow.
Earlier we had one folder 'journal_local', when the remote would be
setup a new folder called 'journal' would be created, and each all the
files would be copied over. This meant the local history was being
destroyed.
Now, we only have 1 folder 'journal', and on 'cloning', we add the url
as a remote, and do a git fetch + merge.
This simplifies everything drastically, and opens the door for multiple
remotes.
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.
This way all the persistant state of the app is managed from the same
place. It makes everything much easier. Also, it's required for when
GitJournal supports multiple repositories.
I'm testing this with the Foam documentation. This has revealed a number
of bugs in our link resolver - most of which have now been fixed.
The graph layouting is not being done as this is so incredibly slow.
This has been added as an experimental feature.
Make it a ChageNotifier and try to access it through the Provider
instead of like a global variable. This way, the state is better
managed and it'll be easier to split out Settings into smaller classes.
That way we don't need to toggle it each time.
Maybe it would be nice to have this exposed via the settings as well,
per editor. So I could enable it / disable it per editor.
Disable the optimization of not checking for pro mode on boot. The
optimization fails and pro members cannot always get the pro features.
This is not good.
As a workaround, opening the but pro mode page also checks if already
purchased.
