search

amake / orgro

An Org Mode file viewer for iOS and Android
https://orgro.org
GNU General Public License v3.0
452 stars 21 forks source link

Open relatively linked HTML files #70

Open nitincodery opened 1 year ago

nitincodery commented 1 year ago

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 commented 1 year ago

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

nitincodery commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

nitincodery commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/hpoul/file_picker_writable/pull/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 commented 1 year ago

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 commented 1 year ago

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

nitincodery commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

amake commented 1 year ago

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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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

nitincodery commented 1 year ago

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 commented 1 year ago

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 https://github.com/amake/orgro/issues/70#issuecomment-1381752506.