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

Create Share Portal #38

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Create Share Portal #38

wants to merge 1 commit into from

Conversation

danirabbit
Copy link
Member

@danirabbit danirabbit commented Nov 9, 2021

Sets up a dummy share portal to start hacking on! Fixes #56

Todo:

  • Create a Granite branch with a function to call this portal so we don't need to manually DBus
  • Show a list of apps that accept this file type as in "Open With..."
  • Show contractor actions that accept this file type
  • Include Mail and Wallpaper portal actions?

@danirabbit
Copy link
Member Author

It looks like from our prior art on the linked issue that it might be valuable to design this from the start as accepting a string array for the files. This makes sense for example if you want to select 3 or 4 things in Photos and then share those in an email

@Marukesu
Copy link
Contributor

Maybe a little soon, since you started on working on it now, but..

Create a Granite branch with a function to call this portal so we don't need to manually DBus

Well, we would need to provide the DBus frontend, backends aren't exposed to the sandbox, it would end begining a new --talk-name=org.freedesktop.impl.portal.desktop.pantheon for apps.

If the idea is of a backend-less portal (since it's a non-standard portal like the IBus and Tracker ones) this shouldn't be exported in the XdgDesktopPortalPantheon.vala, or begin a org.freedesktop.impl.portal interface.

for the frontend we could use a org.freedesktop.portal.elementary since the OnlineAccunts need a frontend portal too.

Show a list of apps that accept this file type as in "Open With..."

IMHO, the Share Portal and OpenURI Portal are different user cases, with the OpenURI begin the better in the case of a "Open with…" menu.

  • a "Open with…" menu should show applications that can open the file (for example, open a text file in code).
  • a "Share…" or "Extra Actions…" menu would show application that can handle that file in some type (for example, add a file in a tar archive in file roller).

we could use the Desktop Actions if the application declares that support the content_type, but i think that can show a lot of false positives.

anyway...

Show contractor actions that accept this file type

this seem duty of the frontend (assuming this is only a backend), like how the AppChooser don't search for the applications or update the choices by itself.

Include Mail and Wallpaper portal actions?

I though about it when thinking in a contractor portal, the problem is the method call need to be done from inside the sandbox, because the app-id is get from the call itself, not as a argument.

Also, calling the backends directly seems silly since the frontend do validation and provide/convert the arguments that the backend expect (for example, the attachements on the Mail portal are file descriptors, but the backend receive uris instead), and would make this portal be more complex since we would need to do the validation by ourselves.

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

Successfully merging this pull request may close these issues.

Granite.ActionSheet
2 participants