Both this calendar view and this history screen need a lot of work to
get them to a place where they can be shipped, and there are no plans of
doing that.
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.
Not everywhere, but a large part of the code base.
This way, hot reloading will also reload the strings which makes for
such a better developer experience.
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
Now that dart-code-metrics has been updated, this lint can finally be
used. So far all of these are false positives, in the sense that I don't
care about their return values.
I wish there was an easy way of marking functions whose return value
shouldn't ever be ignored.
Even though I'm not using v4.2, the return-value rule is still being
applied with `flutter analyze` though not consistently.
For now, lets disable this, as there are 300+ warnings to fix.
A note has a parent which is the physical folder it is inside, and a
parent folder which it is being displayed inside. It's useful to have
the latter as that can be used to display the next note - in the case of
the Journal Editor, and open the graph view as well.
This allows you to long press on a note and select it, thereby allowing
you to perform actions on it, without opening the note.
This is disabled for note, as it isn't completely implemented. I'm not
sure how to pass down the informatin on which Note is selected.
Expose the noteTapped and noteLongPressed functions from all the views.
This will be required in the future as we support selecting a note (or
multiple notes) in order to perform some action on it.
Right now selecting a note means opening the Note Editor.
This basically asserts if we move to a route without a name. This way
I'll always catch when a route doesn't have a name, and I can start
getting better analytics on which screens are used most frequently.
