Use local folder(s)

[alensiljak]

Let me extract this proposal from #5, to allow some focus.

Preface: As I mentioned in a comment there, Flutter has an option (at least on Android) to request permissions for a folder on external storage. This provides access to the whole tree below the selected location.

Proposal: Allow opening a folder location on the device and reading all the files in there.

• option to select a local folder
• display the tree structure for the sub-folders
• allow opening any .org file from the tree

This relates closely to #34, as it would use direct access to the files, without the content provider, so the files could simply be re-read after they have been edited in an external editor.

It will actually allow any sort of interaction with other applications in the OrgMode ecosystem, as well as having attachments, relative links, images, etc.

[alensiljak]

A reference implementation for folder access can be found in GitJournal.

[amake]

In v1.18.1 Orgro uses directory permissions to resolve relative file links between Org Mode documents.

If there is more or different functionality desired, please provide more detail. But note that I don't intend to implement a directory view.

[alensiljak]

Thank you.
There are some issues providing access and following the file links on Android 10.
I've added org_flutter to GitJournal and will focus more on the functionality and the improvements in the library. It seems to fit better my current use case with a couple of mini wiki-style notes folders.

[amake]

There are some issues providing access and following the file links on Android 10.

Could you be more specific?

[alensiljak]

There are some issues providing access and following the file links on Android 10.

Could you be more specific?

Sure. The Grant Access buttons (on top and when tapping the actual link) don't seem to do anything.
Tapping the link to an image reports that there is no app which handles the file type.

[amake]

don't seem to do anything

Doesn't seem to do "anything"? Does it bring up a directory chooser? What directory did you choose? Where are the root file and the target file relative to the directory you chose?

Tapping the link to an image reports that there is no app which handles the file type.

Images are displayed inline if they can be accessed. Otherwise it's up to the system to know how to handle such a link, but generally the system will not know how to handle a relative link like that. So this is to be expected if you haven't successfully granted access.

[amake]

I've added org_flutter to GitJournal and will focus more on the functionality and the improvements in the library. It seems to fit better my current use case with a couple of mini wiki-style notes folders.

I should note that any amount of work on org_flutter itself can't resolve any of the issues you're having, because pure Dart is insufficient for doing so: links and (local) images must be resolved with cooperation from the platform. org_flutter punts on handling these things because they end up intricately tied up with your app's UI, and there is no one-size-fits-all solution.

So to get links and images working you will need to reimplement a lot of the plumbing I have in Orgro inside your own app.

[alensiljak]

So to get links and images working you will need to reimplement a lot of the plumbing I have in Orgro inside your own app.

I get that. Fortunately, these things (links, backlinks, images, etc.) are already taken care of for Markdown so I can borrow them for Org files.
Once I have some time, I will send some ideas or pull requests. I.e. the checkbokes could render the Unicode characters like ☑.

[amake]

I get that. Fortunately, these things (links, backlinks, images, etc.) are already taken care of for Markdown so I can borrow them for Org files.

Nice. I just tested it out in Git Journal and I see that your use case is much simpler: you have direct access to all of the files since you own them by virtue of cloning them into your app's private space.

All of the complexity in Orgro is due to trying to work with files that it doesn't own; in particular the Storage Access Framework on Android is extremely limiting.

[alensiljak]

That is true (I actually hate going back to native development but hey). However, there is also an option to use external storage. That way I can set the storage to be on my "Internal Storage/notes", which is synchronized using rclone. So, completely outside the private app space. It does require a permission (actually, I've fixed that recently for Android) but works well. If you're interested, check that scenario out. You are more fluent with Dart and Flutter, anyway.

[amake]

It does require a permission (actually, I've fixed that recently for Android) but works well. If you're interested, check that scenario out.

Are you talking about GitJournal/GitJournal#448? If so, that solution will not work long-term because you will be forced to target API 30 in September 2021 at which point requestLegacyExternalStorage="true" will no longer work.

If that's not what you're talking about then I'm curious how you did it.

(Also I should point out that this use case is still quite simple since you're guaranteed that all files are located and linked within a directory tree that you have access to. Orgro can't have that guarantee unless it requires you to grant access to the root of the storage tree, which I didn't want to do.)

[alensiljak]

Are you talking about GitJournal/GitJournal#448? If so, that solution will not work long-term because you will be forced to target API 30 in September 2021 at which point requestLegacyExternalStorage="true" will no longer work.

Possibly. Do note that it is May 2021 and the solution above works. When it stops, it will be adjusted to whatever the possible solution is at the time.
My phone is on LineageOS 17.1 and will stay that way for the foreseeable future. So I'm sure the solution above will continue to work for a fairly long time, too. At least, it will for me.

(Also I should point out that this use case is still quite simple since you're guaranteed that all files are located and linked within a directory tree that you have access to. Orgro can't have that guarantee unless it requires you to grant access to the root of the storage tree, which I didn't want to do.)

I would beg to disagree. The use case is identical. My files have been accumulated over the years and are not tied to GitJournal or Orgro. Whichever software adapts to the notes and the way they are linked (because the notes are where the real value lies for me) will be the one I end up using and contributing to. At least that's my view of the situation.