- Allow content to be passed between sandboxed applications. eg:
- Attach a document to an email.
- Edit a picture that you are viewing.
- Send a contact to a friend via chat.
- Access to system services from sandboxed applications. eg:
- Send a contact via Bluetooth.
- Set a picture as your wallpaper.
- View a photo on your TV using DLNA.
- Copy to the clipboard.
- Post to online accounts. eg:
- Post a photo on Twitter.
- Post a video on Facebook.
- Share a link to a blog post on Google Plus.
- Upload a photo to Flickr?
- Other potential system share points (might be out of scope):
The design must be secure, and be consistent with application sandboxing.
The user must approve all share operations through a system-owned (ie. not generated by - or under the control of - the sender application) user interface. Two reasons for this:
- If applications have a role in selecting which share point is used, a malicious application could send content items to a different destination than the one intended by the user.
- Applications should not be able to share items without user approval - this requires that the system checks whether the user consents to the share action.
Firefox F1 is still in development.
In the above screenshot, the list of contacts are Airdrop recipients.
Sharing in iOS 8 is implemented as a type of extension. Extension types are:
- Today: widgets that are displayed in the "Today" view.
- Share: for posting to social media, etc. Allow a content item to be viewed, edited and annotated before being posted.
- These can be editors or views. They can send a content item to another app, or appear as a modal dialog over the sender application.
- Action extensions can be accessed from the share dropdown, from text selection popovers, or an extension toolbar button [not sure what this looks like in practice].
- Photo Editing: only used in the official Photos app.
- Finder Sync: the app registers a folder, which is presented in the Finder UI, along with badges and context menus (this sounds like a Nautilus extension specifically for sync).
- Document Provider: allows an app to feed content into document pickers.
- Custom Keyboard: adds a custom keyboard.
- The user clicks on a share button within the application.
- At this point, the application sends a content item to the sharing framework.
- A share dialog appears over the sender application window. This:
- Is completely system-owned - the application has no ability to affect it.
- Lists available share points for the content item.
- When the user selects a share point in the dialog, the content item is sent to the appropriate destination.
- The destination receives the content item. At this point:
- The destination application is activated - a window is shown, which should display the content item that it has received.
- Or the destination application returns a dialog, which is displayed over the sender application. This should enable actions to be taken in relation to the shared content item, such as posting to a social media site.
- Optional: in editing cases, the destination application can return the content item back to the sender application in a modified form.
TO DO: figure out how this relates to the existing sharing settings. These might need rebranding as something else.
The share interface should be an extension of org.freedesktop.Application, which needs to be implement inside GTK+ itself: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
- g_desktop_app_info_get_implementations() should be used to list all the possible applications that implement the "Share" interface.
- Parenting the share dialogue to the window cannot be implemented in a separate process in Wayland (a-la passing XID under X11) so it needs to be in the compositor to parent correctly (or it could be a system modal dialog, that is implemented in gnome-shell).
- For the "edit picture" case, the destination application needs to be able to send the item back to the source application. Maybe the broker could handle that using a (random) cookie?
- For the "View on DLNA" and "Copy to Clipboard" cases, the share point would probably be implemented by the sender application (“View on DLNA” requires the application to control the playlist/slideshow, potentially adding/removing items as the presentation is on-going).
- When requesting the broker dialogue, the application would be able to add items to the broker page, that would send the content item back to the application. These sender provided share destinations should only be possible for a hard-coded list - this is to avoid the application mimicking other software. (This could also be how "Print" is implemented.)
“Print” for things other than canned files (PDFs, PostScript) that represent exactly what needs to be printed would be problematic to implement as a separate process. For example, changing the margins of the printout in the “Print” dialogue would require relayouting of the data to be printed. The target application might not know how to do that. It’s possible that we can implement this in the future, generating previews and setting up printers in the source application, and then sending out PDFs to a target, system-provided, application. This would require re-engineering the print dialogues and a portion of the current printing workflow is is currently out-of-scope.
- gnome-shell (application selection “broker” dialogue, dialogue parenting from external applications in some cases)
- GLib/GApplication (API extension)
- GTK+ share button helper (calls out to broker)
- xdg-list (upstreaming of API after first implementation)