Ability to present flatpaks with a list of installed apps + their mimetypes
hanaral opened this issue · comments
Problem
Currently flatpaks have no way of just doing 'open in X' from a context menu, because they cannot judge what other apps are installed and cannot open them. This is a pretty basic and expected feature, it especially will effect apps like Code or Photos (there are probably more and it will be exceptionally painful for AppCenter devs).
| ouch | yikes |
|---|---|
 |
 |
Proposal
Maybe for now there should be some kind of launch daemon that checks the list of apps installed and their associated mimetypes so it can present the list to different apps, rather than building a sharesheet from scratch (since this will be an expected feature at 6's launch)
I'm aware this issue doesn't quite fit here but I have no clue where it should go.
Prior Art
Files:
Flatpaks are meant to use the OpenURI Portal for open file outiside the app sandbox, both apps need to be updated to use the portal instead of searching for apps inside the sandbox.
it means that the sub-menu will be replaced by a dialog trough
Are you sure it isn't the app chooser portal? https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.AppChooser
The AppChooser portal is the Backend of the OpenURI one, when you call the OpenURI portal it checks if there's a default app, otherwise it shows the AppChooser Portal, AppInfo.launch_default_for_uri already uses the portal, but since in the case of open in we want to show the dialog anyway so we need to do the call manually or with libportal.
OK, but there really does need to be some kind of replacement before Odin releases, even if it’s ghetto af.
It would probably be helpful to add the ‘open with ...’ button to the bottom of the cont. menu so that there are as few clicks as possible.
Again, having an name+icon that directly shows the name of the app in the context menu is still the best solution if possible (it probably is, but it’s not going to be as easy as a popup )
@hanaral we're purposely not shipping those apps as Flatpak with "Open In..." menus until the design is sorted out. But yeah listing apps inside another app is going to go away. This behavior has privacy implications. You wouldn't want an app like Facebook being able to see what other apps you have installed.
This behavior has privacy implications. You wouldn't want an app like Facebook being able to see what other apps you have installed.
Very true, but you're going to have to come up with one hell of an alternative to the expected toplevel 'open with (default app)' button. I can sort of get over the 'open with another app' becoming a button that opens a dialogue, however not telling the user what you will do when opening the default associated app is quite a spicy change that may result in a lot of user frustration
Either way I'll add any comments of other OS's solutions for ideas
Here's what iOS does:
| Having and file selected in Files | tapping the ••• button | tapping share |
|---|---|---|
 |
 |
 |