Add a sharing portal

[matthiasclasen]

The idea for the sharing portal is that applications can describe support for this in their desktop file:

Implements: org.freedesktop.Share ...

[org.freedesktop.Share] Types: images, text,... (mimetypes)

[pontaoski]

A simple idea for a potential d-bus API (interface: org.freedesktop.Sharing)

methods:

• ShareFiles
  • "file", ah, in: an array of file descriptors
• ShareLinks
  • "link", as, in: an array of links

I don't know any use cases where an application would want to know the result of sharing, so I didn't bother including them.

As far as actually implementing it, I'd say it should probably be up to the backend to do whatever it wants to do with the files/links being shared. KDE's portal could call Purpose, and GNOME's portal could use whatever infrastructure GNOME has for sharing, if any.

[mardy]

I don't know if it matters, but in Ubuntu for phones we had two actions for sharing: one was actually sharing, the other was exporting. I don't think it made a difference in how the content was handled, but from the UI point of view they were different actions; and each application could register itself as a receiver/handler for either action (or both).

• share: ultimately share with people (upload, send a link by SMS, etc.)
• export: send to another application for storage or further processing

[swick]

Looks like Web Share will be a thing and something we probably should try to be compatible with.

https://www.w3.org/TR/2022/PR-web-share-20221215/

[imhemish]

Something similar: #937

[CutestNekoAqua]

I think this is really useful and really important to have. Its super useful and on android it makes it SUPER easy for developers to add application interoperability.

[SaphiraKai]

Agreed, being able to send files and data between applications without breaching any sandboxes is almost necessary, in my opinion.

[soccerboys2008]

I'd like to see something like this implemented

[andyholmes]

Let's all avoid the "me too" comments and just hit the :+1:, otherwise everyone subscribed will keep getting e-mails.

[CutestNekoAqua]

I think what we need is a maintainer telling us what is needed for this to get work on :) Am happy to help

[jadahl]

I don't think any maintainer has a clear idea of how a "share" portal would work exactly, so a way to help is to gather information about how other platforms (Android, iOS, Web Share API for example) does this, try to summarize, and then see how we can learn from that and if suitable see how it can be done with the building blocks we rely on (.desktop files, portal D-Bus APIs, etc).

It'd also be useful to gather information about potential existing applications that could make use of this portal, both in a "shared to" manner and "sharing" manner, or both.

The description of the issue have some very rough idea of how it could work (e.g. how to let an application advertise what it can be shared), but it's only a very bare boned starting point of an idea.

[MikelJohnson]

Hi! I've been thinking about this for a while and for the last four days I've been working on a small POC prototype. It's rough around edges, but I think it's a good starting point if nothing else Here's the repo MikelJohnson/share-portal-poc. I go into a pretty detailed explanation of implementation here

I've also recorded a demo of the sharing process and a demo of an app dynamically adding contacts to the share sheet

I hope this will give some inspiration on how the final api might look like.

[Mikenux]

We may want to differentiate social apps from viewing and editing apps, in order to have clean user interfaces.

[andyholmes]

We may want to differentiate social apps from viewing and editing apps, in order to have clean user interfaces.

I think that's a good point, but this should be doable from the implementation side with .desktop entry categories?

Something related worth considering is dynamic items, like contacts or bluetooth devices that could have offline/online state. Is that something a portal needs to negotiate, or maybe that's irrelevant to the application anyways?

[Mikenux]

I think that's a good point, but this should be doable from the implementation side with .desktop entry categories?

It's a good question. It is certainly the easiest way, if it is assumed that few developers would lie about it. The complex way is to have clues like the app uses a specification to give its contact list, "chat notifications", etc.

Also, I forgot to add the "subtypes" of social sharing: chat (contacts), post (on social media), and upload (uploading a file to a file-sharing web service).

For other things, I don't know. The only thing I can say is that the contacts are not so dynamic (i.e. as if presented in a UI only if they are online).

[orowith2os]

I ended up bringing this up again, here's what I had (from scratch):

• preferred app categories for what to share with
• the content itself with mimetypes wrapped around it
• preferred appid(s) to share with

And some additions to desktop files:

• ways for an app to say it can take in shared data, and describe how
• mimetypes the app supports
• what the app will do with that information (very short - see GitHub mobile's share name when going to share anything to it for reference)

[jadahl]

I ended up bringing this up again, here's what I had (from scratch):

I suggest reading through the precious discussions, and doing the expected research, instead of inventing things from scratch.

preferred app categories for what to share with

Use case for this? Why shouldn't the user be allowed to be in more direct control of what they tend to prefer to share things with?

the content itself with mimetypes wrapped around it

Probably want fd passing for the content.

preferred appid(s) to share with

Apps are isolated by default. What apps will have app IDs to list, and why would they want this?

[orowith2os]

I suggest reading through the precious discussions, and doing the expected research, instead of inventing things from scratch.

Inventing it from scratch isn't the goal - laying out how it might work is. And then comparing with the current work to see if it helps any. I also didn't care to try and find this issue when initially doing so. From now on, I'll be taking the entire thing into context.

Use case for this? Why shouldn't the user be allowed to be in more direct control of what they tend to prefer to share things with?

Hence the word "preferred" - for example, Krita might want to share its images first and foremost with an image viewer application, and so could signal that with the preferred categories. Any applications supporting the mimetype would show in the resulting menu, with apps fitting into the specified categories being put at a higher priority if implemented as such in the portal backend.

Probably want fd passing for the content.

We can probably take from how the Wayland protocol works here too with drag-n-drop.

Apps are isolated by default. What apps will have app IDs to list, and why would they want this?

Applications within an ecosystem might want to put a higher priority on applications in their ecosystem to share with - for example, Inochi Creator (Inochi2D) might want to put Inochi Session as the first and foremost application to share its exported files with. And then other applications supporting the .inx and .inp file formats can show below that.

This would be useful for tighter ecosystem integration in e.g. GNOME and KDE.

[Mikenux]

Hence the word "preferred" - for example, Krita might want to share its images first and foremost with an image viewer application, and so could signal that with the preferred categories.

In my opinion, it's up to users to choose what they want to do, not the app itself. This also means defining which categories can be used and how to handle the possible addition of new categories. If categories are to be used, starting, for example, with "Open with" and "Social" and the app can only choose one, that's a start and makes sense in relation to what we see in the app ecosystem and users might want. There can be more categories, but putting some constraints on their use (so that an app does not use too many categories to appear everywhere), and only for user experience reasons (and not for the will of app developers) seems to me the way to go.

[razzeee]

The appstream categories / subcategories might be a bit problematic for this. In general, they seem very old and in a need of an update.

https://specifications.freedesktop.org/menu-spec/latest/apa.html

[orowith2os]

In my opinion, it's up to users to choose what they want to do, not the app itself.

This would not infringe that freedom.

[Mikenux]

@orowith2os:

Yes, that wouldn't infringe it. However, by presenting apps of a specific category before others, you are somehow suggesting that there is a high probability that users will need these apps before the others. You will reflect this even more if more than one category is used. Also, in the UI, I think one will certainly expect a "Recently Used" section to be displayed first. If categories are to be added, even if they are optional, I would see them more as filters to find specific apps rather than a "main" element in a user experience.

Personally, I would remove anything that looks like promotion or self-promotion, which is more the scope of the app stores. However, I understand self-promotion of apps better if they are part of a suite from the same developers, like LibreOffice and Inochi2D. Knowing whether it is something that should be displayed in a user interface with other apps or as an entry in the app user interface (e.g. an "Open in Inochi Session" entry in a menu), that's another question.

[orowith2os]

@Mikenux I feel like you're trying to complicate this far more than it needs to be.

[Mikenux]

What am I trying to complicate? I'm just giving my opinion to make you understand that this part is not convincing (even if we forget my comment on the promotion). It's up to you to be more convincing and better explain the interest in light of the comments on this part of your initial proposal.

[Mikenux]

Just for convenience, does it seem reasonable to only discuss file sharing ("open with" and social) here and discuss links in another issue?

Also, the issue https://github.com/elementary/portals/issues/49 mentioned here made me think about selecting an app to add a task, event or reminder from a link or a text selection such as, for example, a date or an event. Is this something to discuss as a global topic in another issue, in this issue, or based on what is being shared (i.e. a file, a link, a text selection)?

[orowith2os]

Just for convenience, does it seem reasonable to only discuss file sharing ("open with" and social) here and discuss links in another issue?

Both would be in scope of the Sharing portal, we should discuss how to go about it here.

Not sure how much overlap there would be with the OpenURI portal.

[Mikenux]

Ok. For the OpenURI portal, as I understand it, it's also about selecting a default application (e.g. always open web links in preferred web browser), and we don't want that option here.

I would still like to know why it would be interesting that an app has the possibility to display certain categories of applications at the top of the list. I'll see this anchored more in a specific rather than general user experience (i.e. where we show all relevant apps relative to a file type or extension, or (web) link).

[MikelJohnson]

Hi, as someone who has created a prototype with a somewhat functioning spec, I'd appreciate if you had a look at it, cause I'm pretty sure it covers all the usecases laid out in this convo.

On Sat, 16 Sept 2023, 18:05 Mikenux, @.***> wrote:

Ok. For the OpenURI portal, as I understand it, it's also about selecting a default application (e.g. always open web links in preferred web browser), and we don't want that option here.

I would still like to know why it would be interesting that an app has the possibility to display certain categories of applications at the top of the list. I'll see this anchored more in a specific rather than general user experience (i.e. where we show all relevant apps relative to a file type or extension, or (web) link).

— Reply to this email directly, view it on GitHub https://github.com/flatpak/xdg-desktop-portal/issues/12#issuecomment-1722249096, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVIDEPFT7XYCILSBYFCRMVLX2W54RANCNFSM4CHNMIQQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[orowith2os]

The categories and appids are just hints to the portal for what to show the data with first - the portal is not forced to follow them.

The intention is for e.g. a GNOME app to put a higher priority on sharing, say, an upscaled image with an app in the GNOME ecosystem, and a KDE app to do the same. Or, for some niche cases (like Inochi2D) a higher priority is put on a specific app, as not much else is likely to use its file types or anything.

The user is ultimately the one who chooses what gets what. If the portal wouldn't like this, it can just not follow it, and share with whatever.

[Mikenux]

@MikelJohnson: I took a look at your proposal months ago, but indeed never gave any feedback on it. So here is, but this concerns everyone.

App Actions. The problem with actions is that apps can define as many as they want. Also, when I see screenshots of Android and Apple systems, as well as actions on my iPad (iOS 12, so old), I never saw many actions for apps. Also, certain actions sometimes seem implicit to me. Examples: If I know that an app is a video editor, then I don't need an "Edit Video" action; If I know that a music player with a music library supports playlists, I probably don't need the "Play" or "Add to Playlist" actions, as they can be handled app side; If I have a Note app with notebooks, actions like "Create New Note" and "Add to Notebook" can be done on the app side. We might prefer to explore this and see if we can standardize relevant actions. I noted that in case of events, tasks and reminders, one can have different actions like "Create" and "Attach to" (to open a file in case of an event or task) which seems useful, or simply "Event", "Task", "Reminder" (not really actions, but perhaps more meaningful; they can also be linked to default apps for example). (@orowith2os: Are the categories you're thinking of also like actions, like you mentioned "image viewer" - so a view action?)

Contacts. A contact portal may be preferred if we want to merge contacts (in a UI: select contact > select service [including email] to send with). This can also allow you to list contacts from the same service in order to send to several contacts.

However, I think we really need to know what desktop environment developers want:

• An Activity sheet? Includes devices, “open with” (view/edit), contacts, social apps, general actions (e.g. copy or paste to [app], save to [remote storage app], event, task, reminder), perhaps also the internal actions of the app.
• An “Open with” sheet and a Share sheet (i.e. social: devices, contacts, social apps) with possibly some general actions?
• A user interface that shows as many items as possible to the user?
• Should the UI have all items directly visible? (vs. a scrolling view)

That's all I can say.

@orowith2os:

The intention is for e.g. a GNOME app to put a higher priority on sharing, say, an upscaled image with an app in the GNOME ecosystem, and a KDE app to do the same.

It's good to think about integration with the ecosystem of desktop environments, but don't forget that it's also something that apps not part of such an ecosystem could use (if you only think about applications developed "by" GNOME or KDE).

Or, for some niche cases (like Inochi2D) a higher priority is put on a specific app, as not much else is likely to use its file types or anything.

Pay attention to what you write. Reading "niche cases" and "as not much else is likely to use its file types or anything", then I might ask you "So why include this since this app will be clearly visible?". You're not selling your idea very well here.

[orowith2os]

(@orowith2os: Are the categories you're thinking of also like actions, like you mentioned "image viewer" - so a view action?)

The categories I'm thinking of are like the ones in desktop files, saying what categories an application falls into. Actions are a different problem, and I would like to see them available (preferably specified in the desktop file of the applications) too.

No, I will not be budging on specifying app categories in the portal.

Pay attention to what you write. Reading "niche cases" and "as not much else is likely to use its file types or anything", then I might ask you "So why include this since this app will be clearly visible?". You're not selling your idea very well here.

This is just one use case. I'm sure you can find others. We shouldn't be decreasing usability for these apps when they're also usable for other, more widely known, apps, and when you mix in some globs (e.g. org.gnome.*). If some globs just aren't useful for one desktop's vision, it can just ignore them. Again, preferences. Not rules. Preferences.

---

On a side note, someone working on Calls apps for the relevant ecosystems (KDE, GNOME) should also be brought in for discussion on the Contacts portal, and we can split that into its own issue.

[Mikenux]

@orowith2os:

Ok. We'll see what DE developers think of your idea.

Pay attention to what you write. Reading "niche cases" and "as not much else is likely to use its file types or anything", then I might ask you "So why include this since this app will be clearly visible?". You're not selling your idea very well here.

This is just one use case. I'm sure you can find others. We shouldn't be decreasing usability for these apps when they're also usable for other, more widely known, apps, and when you mix in some globs (e.g. org.gnome.*). If some globs just aren't useful for one desktop's vision, it can just ignore them. Again, preferences. Not rules. Preferences.

This was an advice :wink:

[Mikenux]

On a side note, someone working on Calls apps for the relevant ecosystems (KDE, GNOME) should also be brought in for discussion on the Contacts portal, and we can split that into its own issue.

https://github.com/flatpak/xdg-desktop-portal/issues/15

[Mikenux]

Some links in GNOME:

• https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/32
• https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/203
  • Mockup: https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/dialogs/bottom-sheets.png

[Mikenux]

For information, I found at least one case that could belong to the “Open With” and “Share With” (i.e. share with people) categories: personal information management apps. These apps include contact management and calendar, which can open contact card and calendar files. Opening these files belongs to "Open With" when we add a contact or calendar, and to "Share With" when we share a card or calendar, or when we want to send files with an e-mail.

I don't know if there are other exceptions, but if anyone is interested, other hints are needed for such apps, since apps should ideally not belong to both categories.

[Mikenux]

@orowith2os

Regarding the categories, those of the menu specification concern the menu, whereas here it concerns the opening of a file. For example, audio and video categories are not needed when requesting to open an audio or video file with another app. So it makes no sense to have them all for the portal. Additionally, having them in the portal provides control over what can be added if xdg-desktop-portal developers/maintainers don't have much influence on certain specifications. Finally, I think it is important to make support of these categories mandatory for DEs, because the "Open With" experience is also part of an app UX; this way, app developers can be sure that this experience is available on all DEs.

[razzeee]

Using the categories at all is a bad idea.

[CutestNekoAqua]

Using the categories at all is a bad idea.

How so? Thats just a statement w/o reason, except if someone alr stated it above and I was just too lazy to read, which is very likely

[razzeee]

Desktop categories have aged very poorly. The spec is 20 years old and has only been updated in ways not involving categories lately (last category facing changes were in 2012) as far as I can tell.

There also doesn't seem to be someone actively maintaining them.

Looking at, also will raise some questions, as some of these aged poorly - for e.g. app stores rarely use the Network category for browsers, but rename it. https://specifications.freedesktop.org/menu-spec/latest/apa.html#main-category-registry https://specifications.freedesktop.org/menu-spec/latest/apas02.html

https://gitlab.freedesktop.org/xdg/xdg-specs/-/tree/master/menu?ref_type=heads