Thanks for getting in touch!

Being able to share an image in various ways is definitely a valid use-case that we want to cover. In GNOME 3.22, we are going to have support for sharing. We started out small - at the moment it offers you only e-mail and Google Photos. Bluetooth, Facebook, removable storage devices are going to appear in future versions.

Having said that, I realize that we will never natively cover all the different ways in which an user might want to share content. For that we have 'export'.

Since GNOME 3.20, we have some simple non-destructive editing features. ie.  we never touch the original pixel data. So, if you directly use the original file, you  won't have any edits that you might have done. Exporting solves that by rendering to a separate file, which you can delete whenever you want. It will also let you downscale the image to preserve bandwidth, etc..

Generally speaking, I don't want to lead users too much towards the traditional files and directories model. One of the overarching goals of the new GNOME content applications is to provide an alternative to Files (ie. nautilus). It means that those who meticulously organize their content across directories can still continue to do so (that's why we are trying to make Files even better), but others who don't care much about the underlying storage will now have an alternative and there certainly is a good number of such users these days.

Once again, thank you.

On second thoughts, it seems like a nice touch to pre-select the file in the file manager.

(Note that directly manipulating the file might not work for edited items as mentioned in comment 1.)

Here's how to do it:
* connect to GtkLinkButton::activate-link
* use g_app_info_get_default_for_uri_scheme with uri_scheme="file"
* check if the GAppInfo is nautilus, if not return FALSE
* if it's nautilus then spawn it as "nautilus -s file:///uri/of/the/actual/item"

Created attachment 366895 [details] [review]
local-item: Pre-select the file when opening with Nautilus

g_app_info_get_default_for_uri_scheme ("file")

returns NULL for some reason. I don't know why, so this is what I have till now.

Given that gtk_show_uri ("file:///path/to/directory") opens nautilus, we might need to exploit the fact that nautilus (or any file manager) is registered as a handler for the inode/directory MIME type.

In that case, you will need two URIs. One for the parent directory to get the default inode/directory handler, and if that's nautilus you want to pass it the URI of the actual item behind the -s option.

Review of attachment 366895 [details] [review]:

::: src/photos-local-item.c
@@ +165,1 @@
+static void

A GtkLinkButton::activate-link needs to return a gboolean.

Review of attachment 366895 [details] [review]:

::: src/photos-local-item.c
@@ +234,3 @@
       source_widget = gtk_link_button_new_with_label (source_uri, source_path);
+      g_signal_connect_swapped (source_widget,
+                                "activate-link",

Since the source_widget's lifetime isn't controlled by LocalItem, we need to ensure that the signal handler isn't invoked after the LocalItem has been destroyed. The best way to do that is to use g_signal_connect_object. It will disconnect the handler when the LocalItem is destroyed.

@@ +236,3 @@
+                                "activate-link",
+                                G_CALLBACK (photos_local_item_source_link_activated),
+                                g_object_ref (item));

Simply adding a reference will also solve the above issue, but it will also end up leaking the LocalItem.

Created attachment 367013 [details] [review]
Split out the code to create a GAppLaunchContext from a GtkWidget

Created attachment 367014 [details] [review]
base-item, export-notification: Use GAppLaunchContexts to launch apps

Created attachment 367015 [details] [review]
local-item: Pre-select the file when opening with Nautilus

Thanks for all the work!

Please file a GitLab issue if things don't work with Flatpak.