After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 680983 - Have a better way to email files
Have a better way to email files
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 686818 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-08-01 14:18 UTC by William Jon McCann
Modified: 2013-04-04 20:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sendto: We only send mails now (1.26 KB, patch)
2012-09-03 19:16 UTC, Bastien Nocera
accepted-commit_now Details | Review
main: Always and only send e-mails (1.75 KB, patch)
2012-09-03 19:18 UTC, Bastien Nocera
reviewed Details | Review
main: Strip down nautilus-sendto to only send e-mails (234.87 KB, patch)
2013-01-26 16:44 UTC, Bastien Nocera
accepted-commit_after_freeze Details | Review
Add nautilus-sendto binary (15.50 KB, patch)
2013-03-01 23:59 UTC, Bastien Nocera
reviewed Details | Review
sendto: We only send mails now (1.27 KB, patch)
2013-03-04 14:07 UTC, Bastien Nocera
committed Details | Review
Add nautilus-sendto binary (15.22 KB, patch)
2013-03-04 14:07 UTC, Bastien Nocera
rejected Details | Review
main: Strip down nautilus-sendto to only send e-mails (248.56 KB, patch)
2013-03-20 13:56 UTC, Bastien Nocera
committed Details | Review

Description William Jon McCann 2012-08-01 14:18:27 UTC
Currently we sometimes offer a Send To menu item. But this isn't really great for a number of reasons. It is vague, has a bunch of geeky and/or crappy stuff in it, and it largely doesn't work. I think we should just add a simple way to email files directly from a selection.
Comment 1 William Jon McCann 2012-08-01 16:17:44 UTC
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
Comment 2 Mathieu Bridon 2012-08-02 02:42:01 UTC
(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)
Comment 3 Andreas Nilsson 2012-08-02 10:21:30 UTC
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
Comment 4 Guillaume Desmottes 2012-08-03 11:07:35 UTC
Does this mean we are not going to use nautilus-sendto any more? What about sending files over IM?
Comment 5 Bastien Nocera 2012-08-30 23:03:40 UTC
(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.
Comment 6 Bastien Nocera 2012-09-03 19:16:57 UTC
Created attachment 223360 [details] [review]
sendto: We only send mails now
Comment 7 Bastien Nocera 2012-09-03 19:18:47 UTC
Created attachment 223361 [details] [review]
main: Always and only send e-mails

And not anything else, until we've designed it properly.
Comment 8 Bastien Nocera 2012-09-03 19:22:19 UTC
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.
Comment 9 Cosimo Cecchi 2012-09-11 15:55:16 UTC
Review of attachment 223360 [details] [review]:

I think we ultimately want this in, yes. I'm going to request a freeze break for it.
Comment 10 Cosimo Cecchi 2012-09-13 14:57:50 UTC
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 11 Cosimo Cecchi 2012-09-19 19:53:14 UTC
Comment on attachment 223361 [details] [review]
main: Always and only send e-mails

Removing from the patch queue - this is against nautilus-sendto.
Comment 12 Bastien Nocera 2012-10-25 10:21:10 UTC
*** Bug 686818 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2013-01-26 16:44:01 UTC
Created attachment 234476 [details] [review]
main: Strip down nautilus-sendto to only send e-mails
Comment 14 Bastien Nocera 2013-01-26 16:45:06 UTC
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?
Comment 15 Cosimo Cecchi 2013-03-01 21:07:27 UTC
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.
Comment 16 Bastien Nocera 2013-03-01 23:59:10 UTC
Created attachment 237766 [details] [review]
Add nautilus-sendto binary

Restricted to sending files through e-mail, and automatic
zipping of folders.
Comment 17 Cosimo Cecchi 2013-03-02 16:14:26 UTC
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?
Comment 18 Cosimo Cecchi 2013-03-02 16:15:38 UTC
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
Comment 19 Bastien Nocera 2013-03-04 14:07:42 UTC
Created attachment 237987 [details] [review]
sendto: We only send mails now
Comment 20 Bastien Nocera 2013-03-04 14:07:53 UTC
Created attachment 237988 [details] [review]
Add nautilus-sendto binary

Restricted to sending files through e-mail, and automatic
zipping of folders.
Comment 21 Bastien Nocera 2013-03-04 14:10:53 UTC
(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.
Comment 22 Cosimo Cecchi 2013-03-04 14:50:59 UTC
(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.
Comment 23 Bastien Nocera 2013-03-04 14:59:04 UTC
(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.
Comment 24 Cosimo Cecchi 2013-03-05 02:58:45 UTC
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 25 Cosimo Cecchi 2013-03-06 16:03:27 UTC
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.
Comment 26 Cosimo Cecchi 2013-03-06 16:03:48 UTC
Review of attachment 237987 [details] [review]:

++
Comment 27 Cosimo Cecchi 2013-03-06 16:04:08 UTC
Review of attachment 234476 [details] [review]:

++
Comment 28 Matthew Barnes 2013-03-06 16:56:49 UTC
(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.
Comment 29 Cosimo Cecchi 2013-03-06 17:13:20 UTC
(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
Comment 30 Matthew Barnes 2013-03-06 17:31:35 UTC
(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.
Comment 31 Bastien Nocera 2013-03-20 13:56:31 UTC
Created attachment 239357 [details] [review]
main: Strip down nautilus-sendto to only send e-mails
Comment 32 Bastien Nocera 2013-03-20 14:13:26 UTC
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
Comment 33 Cosimo Cecchi 2013-04-04 20:56:55 UTC
Attachment 237987 [details] pushed as e507f27 - sendto: We only send mails now

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