GNOME Bugzilla – Bug 314559
Be able to scale pictures when sending an e-mail
Last modified: 2006-09-06 20:58:21 UTC
When you select a number of pictures and send them by email, F-Spot should ask if they should be re-sized to save bandwidth during sending. A typical photo is between 1-3 MB in size in original format, same photo scaled down a bit will end up around 50k.
Created attachment 51377 [details] [review] Patch A patch that allows the user to scale the pictures to Tiny, Small, Medium, Large, X-Large or keep in Original size.
The patch is missing the needed update to Makefile. Please insert $(srcdir)/SendEmail.cs \ as below $(srcdir)/RotateCommand.cs \ $(srcdir)/ScalingIconView.cs \ $(srcdir)/SendEmail.cs \ $(srcdir)/SlideView.cs \ $(srcdir)/SingleView.cs \
I'm not happy with the dimiss dialog, we really need a patch on the evolution side to deal with removing the files once it is done. This is a general issue and although I applaud your solution, I don't want want to force the user through that hoop
I agree with your comments, since I also did not quite like the dismiss dialog, but did want to clean up the files... But, I could modify the patch to create the files in a /tmp/f-spot/ directory, and as the last thing f-spot does before it quits, is to clean that directory... Not the best, but probably good enough (user should have sent the mail by now I would think)
One more thought, why not "force the user" for the moment, since the other side of the coin is to send a 6 MB large email which will not be possible to 90% of the receivers. As soon as Evolution handles attachments better (including it instead of linking) we can remove the dismiss window. Or wait for input for better way to handle it. As it is I can not use the "Send photos by email" function.
Let me talke to the evolution guys and see what their feeling is.
Any more news on this one?
It doesn't seem right to me to just 'talk to the evoution guys' about this. There are more mail clients out there, why force every F-Spot user to use Evolution? My mom does not understand it when I suggest moving to yet another mail client to be able to send pictures from F-Spot ('and I just moved to Thunderbird so the switch from Windows to Linux would be painless!'). Using /tmp/ seems to be the best solution to me, but maybe not in the f-spot/ dir if that gets trashed on exit (closing F-Spot during sending should be possible). As for the current state of the 'Send photos by email', only a very small audience can use it I think, considering there is no resizing and it does not work with Thunderbird at all at the moment (bug #168585).
Related feature request of being able to change the quality of photos before sending them was sent to the list: http://mail.gnome.org/archives/f-spot-list/2005-December/msg00103.html
Do we have any more information on this one? As it is it is very awkward to send a photo by email for now...
I think that the possibility to send a scaled down photo by email from inside F-Spot, together with the freedom of using whichever mail client they want (within reason perhaps) (bug #168585) is a major feature for normal users. Would it be possible to get this and #168585 fixed, if not perfect, then temporarily ? Unfortunately we missed the dapper train, but still...
*** Bug 338673 has been marked as a duplicate of this bug. ***
Been long time with no news on this one? Any news? And why can we not implement a workaround solution as long as the underlaying fault exists. When a patch exists for the underlaying code, we could use some CONFIGFURE directives to either use the workaround or not.
Just discovered this patch as I wanted to implement it myself. One thing missing: if the user choose 'Original size', the picture is not rotated according to exif. Should be a checkbox somewhere... see #165645 By the way, since all the exports schemes are doing hte same things (resizing, rotating, ...), it could be a good idea to unify the different parts of the code. Apparently, there is a big plan for EXPORT: http://f-spot.org/To_Do "Export * The current export dialogs have placeholders for scaling and tag export. These need to be hooked up now that the exif saving works. * The export code should be broken down into modules and made pluggable. * All the export dialogs need save history about what directories and accounts were used in the past and offer completion in then entries. " ...
Good point :) I agree, rotate the pictures according to EXIF tag would be very nice. As well as possible remove EXIF tags, or perhaps only the non camera tags? Another thing, if you would like to improve this small patch: I never got the "estimated mail size" to work that good. Any suggestion on how to get it to work nice with Evolution/Thunderbird etc and attachments?
Disclaimer: The folloowing lines could appears as 'totally crazy'. If it is, tell me. Trying to see a clean solution to solve the issue described in this bug (temporary resized files), I just had the idea of implementing a virtual fs inside f-spot. With this, a user (read a program like a mailer) could ask for the image ~Photos/resized/800x600/2345.jpg (where 2345 is the id in the database) and f-spot would automagically generate that resized view. Since everything is virtual, no need to clean the temporary directory... I know how to implement things like this with fuse, and I don't know if there is a way to implement virtual filesystem directly in a mono environment. But the main issue is certainly not a technical one. Such a functionnality could also be very useful for other 'Export' methods. What do you think of this ? Btw, if this things looks interesting but too strange to implement in f-spot, there is also a way in the middle. Don't create temporary files in /tmp, just create temporary named pipes. Those pipes don't use any space on the disk, and once opened, they asks f-spot for the resized version. One more time, if it's trully stupid, tell me. Because if someday I read a thing like this, that will be also my feelings...
Forget about the previous comment. One or two beer too much... Good news, it's probably possible to do it cleanly, because evolution is doing it with web images. Try this: - 'new mail' in evolution - put a picture on a web server (local) - from the browser, drag and drop the image to the mail - REMOVE THE IMAGE from the webserver - send the e-mail ==> conclusion of this: Evolution is able to make a local/temporary copy of the attachment. (Note: it works also when you drag and drop, then remove, the send an image from the filesystem)
I think more recent versions of evolution do store a copy so it would probably be ok to call the gnome_url_open then install a timer to silently remove the temp files in 15 seconds or so (to allow variations in starup or whatever).
How about Thunderbird and other mail clients?
Quick patch review: patch 51377 for bug 314559 Compilation: - this patch no longer cleanly apply against up-to-date CVS. Things to modify in SendEmail.cs: - replace 2 occurences of IPhotoCollection by IBrowsableCollection - replace all occurences of photo.DefaultVersionPath by photo.GetVersionPath(photo.DefaultVersionId) Add attachment: - is working with Evolution (2.6): the temp image can be removed before sending e-mail. As Larry suggested, we need to start a timer and then remove the image - is *NOT* working with Thunderbird at all. A new mail window is opened, but without any attachment UI: - for evolution and with a timeout, remove the dialog. - when the mail is sent, you always have a dialog with 2 buttons: 'cancel' and 'send mail'. This dialog should disappear. Missing feature: - when exporting full-size, rotate according to EXIF (optional) Without this patch, the Send Mail command is useless !!!
re #19, people that are setting thunderbird as the mailto: url handler in gnome should write a script that will turn the mailto: url that f-spot sends into the appropriate thunderbird commands. F-Spot simply calls gnome_url_show with the url and I'm not planning on doing other than that for external mailers.
Created attachment 66110 [details] [review] Updated patch Thanks for the great comments :) Appreciate it. I have now modified the patch a bit. 1) Added a timer (30 seconds... which is ok (barely) when scaling 101 photos with Evolution not running. 2) Ensure the stop buttons work 3) Kill windows quickly 4) Removed the actual mail size, since the windows are gone at this stage. Would appreciate if someone could test this one a bit more ;)
About thunderbird... Thunderbird does not support attachment in the mailto line. see https://bugzilla.mozilla.org/show_bug.cgi?id=99055 As they say, it's for security. But you can add attachments to a new mail using sg like that (it works!) thunderbird -remote "xfeDoCommand(composeMessage,attachment=file:/home/sde/IMG.jpg)" As Larry said, we don't have to support thunderbird inside f-spot, but we can provide a script for thunderbird users. This script should be declared as default mail app (in Preferences/Prefered Applications). This script should parse the mailto line and transform it to an xfeDoCommand. BTW, the 'thunderbird -remote' command ends when the window is opened. So, this script should also cp files in /tmp or ... just my $.02
Created attachment 66133 [details] [review] add rotate functionality I like your new patch. Here is an updated version with the option for auto-rotating full-size images
A bug on this bug... the extension for exported files is '.tmp'. should be the same as the original extension. extension really matters for some email-readers/image-viewer
Should this be fixed in PixbufUtils.cs or? public static string Resize (string orig_path, int size, bool copy_meta) { string version_path = System.IO.Path.GetTempFileName (); Resize (orig_path, version_path, size, copy_meta); return version_path; } Don't know what other implications that will cause. Also, the temp name might not be unique if we change the ending to JPG, PNG, RAW or whatever. If we try to send a RAW image, which ending should we have then?
The patch is definitely shaping up. The scaling logic should be using the ImageFile class to do the scaling though, and if it did the rotation issue would already be handled for scaled images, then you'd just need to try to losslessly rotate any non scaled image that was actually a jpeg. The lossless rotation would probably be better handled by extending the RotateCommand code to provide the lossless option and using that here and in the other export logic, that way the general code (and lossless variants) could be shared across all the export paths.
About your first point: the image is indeed rotated if scaled, whatever the status of the checkbox. It's more like an UI problem. The checkbox should be inactive when the user chooses to scale down. About the second: it's just too bad that you did not say that after my first lossless rotation patch for #165645... but I'll do 2 other patches, using a modified RotateCommand instead of JpegUtils.Transform
Larry, about using RotateCommand to do the effective rotation: - it's not a big hard to modify the code to handle also *real* rotation but: - RotateCommand.Execute works on a IBrowseableItem[]. Is it useful to load each images as new f-spot object only for rotating them ? I'm guessing how much cpu time it will take for almost nothing...
Created attachment 66919 [details] [review] Extending the RotateCommand This standalone patch extend the RotateCommand class to handle more rotating methods(RotateOrientation and RotateCoefficients for now). It is backward compatible with previous call to RotateCommand in F-Spot.
*** Bug 346052 has been marked as a duplicate of this bug. ***
What remains to be done on this bug? As I see it 1) Ensure the photos to be sent by email, ends with .jpg (possible modify pixbuf so it can return a unique temp picture name (ending with jpg)) How are flickr handling photos with .tmp? Or I missed somerthing? FlickrRemote is also using the same PixBufUtil resize util 2) Change the 30 seconds delay to GConf variable 3) Ensure the RotateCommand are implemented ok. Any comments?
Created attachment 69410 [details] [review] Bengst Scale Email patch (with rotate..) Made this patch uptodate. Also, modified it so it will use the original file names. The temp files (resized photos) are stored in /tmp/<tmp dir>/<photos> and will be deleted after 60 seconds.
patch review: patch #69410 for bug #314559 pros: - apply and compile with latest CVS - very nice small interface - works well with evolution - tmpdir is deleted after 60secs: ok cons: - no keyboard shortcuts (_) for any control of the dialog - the user can't figure what size (in pixel) correspond to 'Tiny' or ... Maybe a contextual help when the mouse is hover. - no check for uniquename. in this case, you can reuse FileImportBackend.UniqueName(), check bug #335935 and bug #348091 - use original file names for rotated images btw, it's an excellent patch and well-written. the few minor issues should not block this patch for CVS HEAD...
Created attachment 69720 [details] [review] Bengts Scale Email patch Updated with Stephanes comments. Have not fixed the UI shortcuts (_) since I am not to sure how to do this. I also added preferences for DELETE_TIMEOUT_SEC, SIZE, ROTATE Tool tips are added Ensuring emailing Unique filenames And using original file names (made unique though)
if some of you are already in the mood of playing with plugins, here's 2 tips: To enable your plugin automatically AT THE FIRST TIME, do this in the constructor: public DummyPlugin () : base() { //This will enable this plugin at first load Preferences.Get("Enabled",true); } To enable your plugin EVERYTIME f-spot is started, do that Preferences.Set("Enabled", true);
obviously, the comment #36 was not intended to land here ...
Created attachment 69826 [details] [review] BEngts Scale Email patch Slightly updated patch
Perhaps we should remove the Scaling Logic to a separate export common class. And have sending mail by using Evolution as a plugin....
I think the common export class and send mail as a plugin(s) is a good idea. My concern is how long it will take to implement it. Given that this is a goal, that the plugin infrastructure has been started but won't be ready for a month or two, and that the Send Mail feature is fairly useless as is, wouldn't it be better to get this patch in and then refactor it once the plugin system is ready? If we really are going to put off this and other features for the plugin system, we need to make plugins a priority.
Ben (comment #40), yes, we should get this patch in more or less as it is, and then later refactor it to plugin later when the plugin is working fine.
Totally agree with Ben (comment #40)
Created attachment 71453 [details] [review] Bengst Scale Email patch (with rotate..) Slight update of this patch. 1) Refactored one small routine 2) Disable the rotate option, unless Original size is selected.
Created attachment 71491 [details] A script to use as the gnome mail handler which allows the SendMail feature to use Thunderbird Here is a first stab at a script so that Mozilla Thunderbird users can take advantage of the SendMail patch. Set your mailto handler to use a custom handler and put "/path/to/thunderbird-mailto.py %s". Make sure to give the full path, otherwise it wasn't working through f-spot. (works fine in ff and with gnome-open) Current issues: 1) TB doesn't copy the files, so the script makes a copy (we delete the orig inside f-spot). If f-spot isn't running, the script removes its copies when the user sends the message. If f-spot is already running, we can't tell when the user has sent, so the script waits 15 min and then deletes. 2) There may a more concise way to convert the mailto into what TB is expecting, but this works and is clear (at least to me) Please break. Once the bugs get worked out we can provide it to users until we can write a separate plugin for TB users.
Would this effect the other gnome applications? I take it you want to change the prefered mail handler in gnome? Looks great though :)
Yeah, this would change the handler for all the mailto links within Gnome. Like I said, its a hack until we can get plugin support. The plan is to fix any probs people have with it so that its invisible. If it turns into a prob, we could detect that f-spot was the one calling it by the subject=my%20photos, and then do the stuff, otherwise directly call TB, just like if it were the preferred app.
May I suggest we better be a bit proactive and implement this extra fix before someone complains... :) As you also stated, when we get the plugin support working, we will have one plugin per mail client I guess which solves this problem nicely.
I just would like to point you to the project Portland: http://portland.freedesktop.org/wiki/TaskEmail
Created attachment 71609 [details] Same as before, but short circuits if command doesn't come from f-spot Better safe than sorry I guess. This version detects whether it comes from f-spot and makes it work, otherwise it just calls Thunderbird normally. Oh, and Bengt is right, there is nothing in the mailto standard about attachments. See http://www.rfc.net/rfc2368.html
*** Bug 353954 has been marked as a duplicate of this bug. ***
The patch is committed, this bug needs to be closed. Why not opening a new bug entry for the thunderbird mail handling issues and solutions ?
(In reply to comment #51) > The patch is committed, this bug needs to be closed. Why not opening a new bug > entry for the thunderbird mail handling issues and solutions ? > I opened one but was asked to clone to this one. I am a beginner and all those comments on those patches are quiet complicated to follow. Please make a summary adn tell us how we can do this with Thunderbirds ... Thanks in advance, Christian
The patch is actually committed now (sorry for the slight confusion). Bengt I'd like to see the scaling options and the scaling code changed to match up with the other export dialogs still, but I decided we could fix that once it is in. Closing this bug, the thungderbird issue is considered a different bug.