or focus the action on Email which is the highest value operation. It might be best not to hide Email behind the term Send to. I think this should be done without any UI.

 * Select files
 * Right click
 * Email
 * Something zips up directories if necessary
 * Presents an email composer with empty address field

(In reply to comment #1)
> It might be best not to hide Email behind the term Send to.

How about a "Share" submenu with "Email" inside it? (This is how WebOS does it and it does sound better than "Send to")

People could have public sharing space defined in GNOME Online Accounts (Google Docs, SkyDrive,...) and Nautilus could allow the user to make those documents public, share a link to them, etc?

Plus, there's also the file transfer over IM? (which seemed to finally be working over Jabber the last time I tried)

Just a quick note about sharing files over e-mail, since we investigated this in Thunderbird not too long ago. A lot of email servers have a quota of 20MB for recieving files and will bounce your e-mail if it exceeds that size. In Thunderbird we solved this by offering to upload the file to a file service such as Yousendit, Dropbox and similar services if it was bigger than 5MB. Hence I would suggest either doing the file service route thing directly in Nautilus, or in Evolution to avoid bounching files errors.

https://support.mozillamessaging.com/en-US/kb/filelink-large-attachments

Does this mean we are not going to use nautilus-sendto any more? What about sending files over IM?

(In reply to comment #4)
> Does this mean we are not going to use nautilus-sendto any more? What about
> sending files over IM?

I think that needs to be designed differently, and certainly better than nautilus-sendto currently is. Jon demo'd the latest nautilus-sendto to me, and it was absolutely awful, with loads of broken plugins. We want something first rate and integrated.

Created attachment 223360 [details] [review]
sendto: We only send mails now

Created attachment 223361 [details] [review]
main: Always and only send e-mails

And not anything else, until we've designed it properly.

First patch is against nautilus itself, and includes string changes.
The second patch is against nautilus-sendto, and hacks away the UI to only send e-mails.

Jon, if you're interested in having this, the nautilus-sendto code is trivial, and committable, but you'll have to chase it up with Cosimo, r-t and co. to get it past freeze breaks.

Review of attachment 223360 [details] [review]:

I think we ultimately want this in, yes. I'm going to request a freeze break for it.

This was discussed on the release-team mailing list, and it was considered not ready for 3.6; we'll revisit the whole send to experience next cycle then.

Comment on attachment 223361 [details] [review]
main: Always and only send e-mails

Removing from the patch queue - this is against nautilus-sendto.

*** Bug 686818 has been marked as a duplicate of this bug. ***

Created attachment 234476 [details] [review]
main: Strip down nautilus-sendto to only send e-mails

Cosimo, we can commit this to nautilus-sendto, and move the single "nautilus-sendto.c" to nautilus, or release it separately. What do you think?

Sorry for dropping the ball on this...things of course didn't magically fix themselves, so this works possibly even worse than before.

I think a possible plan would be:
- merge the stripped down version of nautilus-sendto into Nautilus itself
- keep the upstream nautilus-sendto as is
- don't ship nautilus-sendto at all as part of 3.8

This will keep the ability for who wants to still use the old sendto to do that without any change, at the only expense of the duplicate context menu item for people that install it.
Bastien, if this makes sense for you I think we should go ahead and try to do this for 3.8, possibly keeping release-team in the loop for eventual ACKs we're going to need.

Created attachment 237766 [details] [review]
Add nautilus-sendto binary

Restricted to sending files through e-mail, and automatic
zipping of folders.

Review of attachment 237766 [details] [review]:

Thanks, this looks generally good - I didn't review the binary helper code.

::: nautilus-sendto-extension/Makefile.am
@@ +23,3 @@
   $(BASE_LIBS)
+
+bin_PROGRAMS = nautilus-sendto

Wouldn't this conflict with the binary installed by nautilus-sendto at the same location?

Ideally in the long run we should have the concept of sharing providers usable through a DBus interface, but until then I think it's better to keep this as a private nautilus helper in libexec (the code spawning the binary should also be modified).

::: nautilus-sendto-extension/nautilus-sendto.c
@@ +52,3 @@
+static const GOptionEntry entries[] = {
+	{ "run-from-build-dir", 'b', 0, G_OPTION_ARG_NONE, &run_from_build_dir, N_("Run from build directory (ignored)"), NULL },
+	{ "xid", 'x', 0, G_OPTION_ARG_INT64, &xid, N_("Use XID as parent to the send dialogue (ignored)"), NULL },

Can you also remove these unused options?

Review of attachment 223360 [details] [review]:

This looks good once we get the other in.

::: nautilus-sendto-extension/nautilus-nste.c
@@ +78,3 @@
 	    !nautilus_file_info_is_directory ((NautilusFileInfo *)files->data)) {
 		item = nautilus_menu_item_new ("NautilusNste::sendto",
+					       _("Email..."),

Should probably be updated to use the unicode ellipsis

Created attachment 237987 [details] [review]
sendto: We only send mails now

Created attachment 237988 [details] [review]
Add nautilus-sendto binary

Restricted to sending files through e-mail, and automatic
zipping of folders.

(In reply to comment #17)
> Review of attachment 237766 [details] [review]:
> 
> Thanks, this looks generally good - I didn't review the binary helper code.
> 
> ::: nautilus-sendto-extension/Makefile.am
> @@ +23,3 @@
>    $(BASE_LIBS)
> +
> +bin_PROGRAMS = nautilus-sendto
> 
> Wouldn't this conflict with the binary installed by nautilus-sendto at the same
> location?

Yes, because it replaces it.

> Ideally in the long run we should have the concept of sharing providers usable
> through a DBus interface, but until then I think it's better to keep this as a
> private nautilus helper in libexec (the code spawning the binary should also be
> modified).

That means breaking all the other users of nautilus-sendto (rhythmbox, evolution, totem, etc.) or still shipping nautilus-sendto with all the ills and problems we know it has, and without a nautilus extension.

> ::: nautilus-sendto-extension/nautilus-sendto.c
> @@ +52,3 @@
> +static const GOptionEntry entries[] = {
> +    { "run-from-build-dir", 'b', 0, G_OPTION_ARG_NONE, &run_from_build_dir,
> N_("Run from build directory (ignored)"), NULL },
> +    { "xid", 'x', 0, G_OPTION_ARG_INT64, &xid, N_("Use XID as parent to the
> send dialogue (ignored)"), NULL },
> 
> Can you also remove these unused options?

I've remove run-from-build-dir but xid needs to stay to be compatible with the way it's used from some applications.

(In reply to comment #21)

> Yes, because it replaces it.

[snip]

> That means breaking all the other users of nautilus-sendto (rhythmbox,
> evolution, totem, etc.) or still shipping nautilus-sendto with all the ills and
> problems we know it has, and without a nautilus extension.

Exactly; I don't want those applications to now depend on nautilus instead of depending on nautilus-sendto. The dependency in those applications should probably be removed entirely or replaced with something else on a per-case basis.

That's why I proposed we keep current nautilus-sendto as it is, and make this a private nautilus helper. One thing that I didn't realize in my previous comment is if we do that, the code adding the "Email..." menu item should be in Nautilus proper, and the extension would work untouched with the old nautilus-sendto.

(In reply to comment #22)
> That's why I proposed we keep current nautilus-sendto as it is, and make this a
> private nautilus helper.

And I end up with a broken nautilus-sendto for one more release because you don't want to take on the name.
I'm really not sure what this brings me.

OK, I thought a bit more about this; how about we don't merge it in nautilus and modify nautilus-sendto to only send emails? Basically what your first patch did here.
That should make everyone happy for 3.8 and avoid too much shuffling, code duplication or maintaining broken features.

I really hope we can get some movement on a real sharing service API next cycle, and get rid of it entirely.

Comment on attachment 237988 [details] [review]
Add nautilus-sendto binary

We agreed with Bastien for the approach outlined in the previous comment, so we don't want this.

Review of attachment 237987 [details] [review]:

++

Review of attachment 234476 [details] [review]:

++

(In reply to comment #22)
> Exactly; I don't want those applications to now depend on nautilus instead of
> depending on nautilus-sendto. The dependency in those applications should
> probably be removed entirely or replaced with something else on a per-case
> basis.

FWIW, Evolution tests for nautilus-sendto via g_find_program_in_path() and disables the integration if not found.  So no hard dependency for Evolution.

(In reply to comment #28)

> FWIW, Evolution tests for nautilus-sendto via g_find_program_in_path() and
> disables the integration if not found.  So no hard dependency for Evolution.

Nice; we're likely not going to remove the binary for 3.8, see [1].

I'm curious as to why Evolution needs nautilus-sendto though, I suppose it's not for emails :-) Would the integration you have still be useful after we stripped it down to only send files by email?

[1] https://mail.gnome.org/archives/release-team/2013-March/msg00057.html

(In reply to comment #29)
> I'm curious as to why Evolution needs nautilus-sendto though, I suppose it's
> not for emails :-)

In the context menu for email and calendar attachments there's a "Send To..." option that invokes nautilus-sendto (if present).


> Would the integration you have still be useful after we stripped it down to
> only send files by email?

Probably not.  I think I'd just replace it with a "Forward Attachment..." option that Evolution would handle directly.

Created attachment 239357 [details] [review]
main: Strip down nautilus-sendto to only send e-mails

Comment on attachment 239357 [details] [review]
main: Strip down nautilus-sendto to only send e-mails

Attachment 239357 [details] pushed as 6cd1c77 - main: Strip down nautilus-sendto to only send e-mails

Attachment 237987 [details] pushed as e507f27 - sendto: We only send mails now

Pushed to master now, since I branched for gnome-3-8.