Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to present flatpaks with a list of installed apps + their mimetypes #82

Open
hanaral opened this issue May 14, 2021 · 7 comments

Comments

@hanaral
Copy link

hanaral commented May 14, 2021

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
flatpak-pain 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:
files

@Marukesu
Copy link
Contributor

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

@danirabbit
Copy link
Member

@Marukesu
Copy link
Contributor

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.

@hanaral
Copy link
Author

hanaral commented May 15, 2021

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 )

@danirabbit
Copy link
Member

@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.

@hanaral
Copy link
Author

hanaral commented May 15, 2021

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

@hanaral
Copy link
Author

hanaral commented May 15, 2021

Here's what iOS does:

Having and file selected in Files tapping the ••• button tapping share
image image image

@danirabbit danirabbit transferred this issue from elementary/settings-daemon Jun 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants