Open preview from another app

[alensiljak]

Hi! I'm slowly adding some basic support for .org files in GitJournal (GitJournal/GitJournal#463), initially only as plain text, and it would be a great step forward if I could simply call Orgro to preview the current file.

Is there a way to open Orgro with the file content to be previewed? What would be the best way to achieve this?
Does Flutter have some mechanism like Android Intents, where one could invoke Orgro with a string content to be previewed? Would you add the missing bits to make this work?

Thanks!

[amake]

Does Flutter have some mechanism like Android Intents

I don't think Flutter has anything special. On Android the app is an Android app (and so on with iOS), so it responds to whatever intents it's been made capable of responding to.

Orgro does respond to intents on both Android and iOS for org files. It doesn't have anything for strings.

But I don't think the UX of switching to another app would be very nice. For one thing, by default Flutter apps are contained within a single activity, so there is no viewer-only activity you can launch; it has to be the entire app. Thus you have to go "through" the top screen, and navigating back would first take you to the top screen instead of back to your app, so it would probably be a bit confusing for the user.

I don't know if there is a clean way to make that specific use case really nice, and I'm not going to pursue it.

If you just want to view a string, I have that entire functionality available as a separate library (which you can actually use since your app is a Flutter app): https://github.com/amake/org_flutter

The caveat is that it is barebones so as to minimize dependencies. If you want to be able to do things like open links or view images, you need to supply the appropriate callbacks to do so.

[alensiljak]

OK, thanks. That's kinda sad because, back at the time when I was going through the design documents for Android, this was exactly the goal of the Android architecture. One did not have to code monolithic applications but could design specific functionality as activities which could be called either from the same app or from any other app out there. The same with Content Providers and other goodies. That, of course, has not really caught up over the years. And, overall, the native mobile development seems too convoluted to me, but that's a different topic.

In terms of usability, there is really no difference in switching to an activity in one's own application vs an activity in any other. But having no Activities in Flutter to begin with is, of course, a blocker.

I think there are ideas (in the GitHub issues) about implementing the library you created into GitJournal but the issue there seems to be licensing, from what I remember. Only through that issue I found that Apple does not allow GPL-ed code on their app store, which is a shame. Otherwise, you are right, this would be a fantastic solution.
Do you release Orgro on Apple Store and are you aware of any such issues?

[amake]

But having no Activities in Flutter to begin with is, of course, a blocker.

It's not that there are no Activities; it's that by default the entire app is in a single Activity.

This makes it sound like it might be possible to set up a separate Activity just for viewing incoming intents. If someone wants to figure that out for me I might consider it, but I don't plan to spend any effort on it.

Do you release Orgro on Apple Store and are you aware of any such issues?

I do. My understanding is that I can do so because I own the copyright on all GPL code in my app, so I am able to distribute it for the App Store under a different license (whatever would be appropriate).

I don't understand how GitJournal can be on the App Store when it is under AGPL and has multiple contributors. Unless they are requiring copyright assignment (I see no evidence of this), the whole of the program cannot be relicensed for the App Store.

If there is interest I could be willing to relicense org_flutter under something more suitable, but again I think GitJournal is already not in compliance.

[alensiljak]

I might have a look into the Activities in Flutter. Will add it to my todo list.

@vHanda should be able to elaborate more on the topic of licensing.
I hope some solution can be found as I'm quite keen to help develop a decent set of tools for OrgMode on mobile devices.

[vHanda]

Hello. I'm GitJournal's author.

I haven't figured out how to do the CLAs properly (I live in Spain), and therefore have been selectively relicensing each file anyone else touches to Apache2. It's not perfect, but it's a temporary solution, while I figure this out with the FSFE lawyers. (Just waiting back to hear from one more person).

I would love org_flutter and org_parser to be non *GPL based as I could then use them in GitJournal and not have to write the org mode from scratch in the future. Org Mode support is one of the top voted issues in GitJournal, and if more people want it I will tackle it at some point.

However I completely understand if you don't want to do that. They are your projects, and you get to decide. The only thing I can add is that my plan is for GitJournal to always be licensed under an open source license.

[vHanda]

Also, if you decide to add Git support to Orgo, I'll be happy to help.

GitJournal uses a combination of libgit2 and an experimental implementation of Git in dart that I've been working on. I'm hoping to soon drop libgit2 completely and have everything in dart.

[amake]

@vHanda Thanks very much for the information.

I licensed org_flutter and org_parser under GPLv3 to match Org Mode itself, because I thought that would be somehow fitting in a poetic sense. But I realize now that it's really an impediment to use in an ecosystem where publishing on the App Store is a major raison d'être.

I will relicense them under something more permissive.

Also, if you decide to add Git support to Orgo, I'll be happy to help.

I prefer to keep Orgro focused on being minimal for the time being, but the offer is appreciated.

GitJournal uses a combination of libgit2 and an experimental implementation of Git in dart that I've been working on. I'm hoping to soon drop libgit2 completely and have everything in dart.

This is very cool. I will keep an eye on it.

[amake]

This makes it sound like it might be possible to set up a separate Activity just for viewing incoming intents. If someone wants to figure that out for me I might consider it, but I don't plan to spend any effort on it.

On second thought, there is probably a way to do it without setting up a separate Activity:

Right now, the way we know to open a file received by intent is to receive an async callback from file_picker_writable. Since we don't know that there is something to open at startup, we must go to the top screen before opening any files.

What we would need is:

• An API on file_picker_writable to check for pending open events
• Before going to the top screen, check for pending open events; if there is one, route directly to the file instead of the top screen
• Figure out how things should behave on iOS, where independent Activities are not a thing (what happens when the user closes the file?)
• Figure out if it's reasonably feasible to have the iOS behavior and Android behavior coexist

[alensiljak]

There's an interesting thing and I don't know if it is intentional. Orgro is offered as an app for handling many types of files, which is great and I'm actually using that to quite an extent, to preview different types of files.
So, for example, if I select an Org file in the file manager, it will offer Orgro among other apps. When I select Orgro, it will display the Org file fine. After the file is closed, the app will go to the top screen, just as expected. The file will not be remembered.
It seems tome that everything required is already there. Or am I misunderstanding how this works?

[amake]

Orgro is offered as an app for handling many types of files

This is kind of an accident of how Android intent filters work. I just couldn't find a way to accurately target *.org files only, so I ended up choosing to cast a very wide net.

It probably offers Orgro for too many kinds of files, but I don't know how to improve it.

After the file is closed, the app will go to the top screen, just as expected.

If this is what you expect, then great. I figured that would not be desired, and you would prefer to be kicked back to the originating app.

The file will not be remembered.

This is not really intentional, but rather a consequence of the fact that you can't get persistent permissions from the kind of intent fired in this situation.

It seems tome that everything required is already there. Or am I misunderstanding how this works?

If the behavior is already as you like, then I think there's nothing more to do.

[amake]

I will relicense them under something more permissive.

I just released org_parser v2.1.1 and org_flutter v1.3.0 under the MIT license.

[amake]

I'm going to close this because it seems like there isn't anything to do.