Open relatively linked HTML files

[nitincodery]

I have org files with links, when I click them nothing happens, wouldn't it be better if it open those links in browser?

https://blog.logrocket.com/launching-urls-flutter-url_launcher/

https://pub.dev/packages/url_launcher

[amake]

They should open in a browser already. Can you give a snippet of Org markup that isn't working as you expect?

[nitincodery]

Oh yes hyperlinks to web link works, my bad, I wasn't clear, I have links to MHTML files linked in org file like this:

[[./html/Tag Searches (The Org Manual).mhtml][Tag Searches (The Org Manual)]

So this file should be opened in browser? but nothing happens on tapping it.

[amake]

That would be a local file reference. I'm not sure it's feasible to compute a URL openable by a mobile browser in all cases, especially for instance when the file is stored in a third-party app like Dropbox or Google Drive.

It may be possible with a file on local storage, but I'd have to look into it. Regardless it's not as simple as calling into url_launcher (which I already use for web links)—mobile operating systems work very hard to obfuscate the location of files for security reasons.

Can you tell me what OS you are using and where you are storing your files?

[nitincodery]

I saw it won't work on android :/ though you can load it via webview_flutter.

[nitincodery]

That would be a local file reference. I'm not sure it's feasible to compute a URL openable by a mobile browser in all cases, especially for instance when the file is stored in a third-party app like Dropbox or Google Drive.

It may be possible with a file on local storage, but I'd have to look into it. Regardless it's not as simple as calling into url_launcher (which I already use for web links)—mobile operating systems work very hard to obfuscate the location of files for security reasons.

Can you tell me what OS you are using and where you are storing your files?

It will be local file path always as, file stored on third-party app will be having https:// url, no? Also url_launcher can load file:/ paths only on desktop platforms. And, the paths are relative to org file itself, like I have a list of links to external org files in different folder, when I tap on one of these links it opens that org file within orgro and then this last file has HTML files links in it which are residing in current working directory, so I thought tapping on them would open browser, like it handled file:/ links a step ago but couldn't handled it at last step. And I am using android 10 and files are locally stored.

[bradyt]

I guess Android narrows down the OS. But by storing files, I think they meant which DocumentsProvider, like Google Drive, Dropbox, etc. @nitincodery. I think they want to know because typically they'll want to test against the particular provider you are using, as each one may fail to implement various methods for the APIs used.

As far as what direction the solution might be in, maybe Android intents, or libraries using them? I don't really know.

[nitincodery]

This app is for android only, so I don't get it which os is a question here even, secondly, I am using file:/ urls which in itself says local files, no document provider like google drive, dropbox.

[amake]

It will be local file path always as, file stored on third-party app will be having https:// url, no?

No, third party apps using the Android or iOS document provider APIs will have very different URIs. See hpoul/file_picker_writable#20 for a small sample of the complexity involved.

This app is for android only

No, it's also for iOS.

I am using file:/ urls which in itself says local files, no document provider like google drive, dropbox.

But any solutions must take into account files stored elsewhere such as in Google Drive and Dropbox.

[nitincodery]

Also, loading local html/mhtml files is possible via webview inside the app, via webview_flutter, but that might conflict with url_launcher when opening websites, so it will complicate the app structure I guess.

[amake]

I will not be embedding a webview to view non-Org files.

[nitincodery]

Ok I didn't knew it is for iOS too, I myself was native iOS developer and now I can understand what actually you meant by external storage, dropbox, drive and all that stuff, its flutter who is managing all that and it will break on different OSes under their different API handling file URLs.

So this PR explains all that complexity I wasn't able to see before, I get it now. So, yeah it must handle those third party providers too.

[bradyt]

Probably off-topic at this point, but just for the record, besides iOS and Android OS, there are other forks like Graphene OS, MIUI, etc. If I understand correctly. Whereas, Samsung Galaxy apparently does use Android OS, just with a different UI.

I've seen issue threads on similar projects, particular to Graphene OS, or MIUI.

Regarding opening files with Chrome, I wonder if Android intents or iOS UTIs are relevant here.

EDIT: And strictly speaking, I think Storage Access Framework is being used, so it's all considered "document providers", local or not. If I understand correctly. At least, with local, we'd expect it to implement the provider side more fully. If I recall correctly, not even Google Drive implements all of provider API yet.

[nitincodery]

I will not be embedding a webview to view non-Org files.

I understand, this will deviate from the goal of being just org file viewer, but opening non-org files inside webview will make it more usable, as people embed non-org files inside links such as images, videos, pdfs, local files, source codes, snippets etc. and just providing webview as fallback for such files will extend viewing non-org files too right inside Orgro.

Just an opinion, in the end its your choice to add it or not, if I'll be able to grasp basic flutter setup in free time, I'll try to create a fork of it and will try to understand it all, and will try to add webview in that fork.

P.S. I really love your app, already shared it over emacs group(s) over telegram and discord to so many people in past and they all felt damn this is so nice!!

Also, I don't know if I should open a new discussion on these visual points:

• hide extra asterisk (*) in front of each level with empty space
• hide #+ meta-data in reader mode
• give different set of random colors to each of todo keywords and done tags instead of single color

[amake]

I understand, this will deviate from the goal of being just org file viewer, but opening non-org files inside webview will make it more usable, as people embed non-org files inside links such as images, videos, pdfs, local files, source codes, snippets etc. and just providing webview as fallback for such files will extend viewing non-org files too right inside Orgro.

Thanks for the feedback. I'll consider it.

P.S. I really love your app, already shared it over emacs group(s) over telegram and discord to so many people in past and they all felt damn this is so nice!!

Thanks very much. I really appreciate the word of mouth.

Also, I don't know if I should open a new discussion on these visual points:

Yes, please open new tickets for each suggestion you have.

[amake]

That would be a local file reference. I'm not sure it's feasible to compute a URL openable by a mobile browser in all cases, especially for instance when the file is stored in a third-party app like Dropbox or Google Drive.

So I took another look at this. It's basically the same problem as opening a relative link to an .org file, except that after computing the absolute URI we're trying to hand it off to another app.

Here are example URIs computed for a ./index.html relative to a test.org:

• Android: content://com.android.externalstorage.documents/tree/primary%3ADocuments%2Famk/document/primary%3ADocuments%2Famk%2Findex.html
• iOS: file:///private/var/mobile/Library/Mobile%20Documents/com~apple~CloudDocs/Docs/index.html

It simply doesn't work on either Android or iOS. Android will let you choose an app to handle the URI, but it will fail to open due to lack of permissions. iOS will simply fail.

So actually embedding a webview or similar in Orgro might be the only way to handle this.

[amake]

Looking at webview_flutter I see that the only really relevant method seems to be loadFile, but this requires

the absolute path to the file as it is stored on the device. For example: /Users/username/Documents/www/index.html.

Unless something has changed or my understanding is wrong, you basically cannot compute such a path on recent versions of Android. You can get closer on iOS, but even then I expect that security scoping would be a problem.

[amake]

Relevant advice: https://indieweb.social/@xenodium/109687491199899937

[nitincodery]

Is it possible to give an option "Open with.." when tapped on relative link to open them in some external browser or application defined in settings as external app to handle links?

[amake]

Is it possible to give an option "Open with.." when tapped on relative link

It is possible to make this UI, yes.

to open them in some external browser or application defined in settings as external app to handle links?

The problem is that there appears to be no way to create a URL that can be handled by the system in the way that you want. See #70 (comment).

[amake]

In v1.48.1 you can open linked files in external apps, and it does work on HTML files, but I don't think the result is what you're looking for:

In order to obtain a file URL that can be shared to other apps, the file must be copied into Orgro's private container. This means that any files or assets linked from the HTML will not be accessible when rendered.