GNOME Bugzilla – Bug 312089
Several minor bugs in "Save All Attachments"
Last modified: 2009-05-13 00:23:04 UTC
There are several minor bugs in "Save All Attachments" in Evolution 2.3.6. They're all probably small enough that I'm going to report them all in one bug. - The mouse wheel doesn't work while the mouse is over the expanded attachment "icon view". Presumably this is because if there are enough attachments, the icon view would include a scrollbar. It's probably better to just always expand the icon view to take up as much space as it needs to show all attachment icons, for two reasons: (1) scroll-pane-inside-a-scroll-pane is never really intuitive; and (2) if you're using the mouse wheel to scroll down your message, it stops when the cursor is over the attachment pane. - "Save All" should probably just say "Save" when there is one attachment, and open the Save As file chooser rather than the "Select a directory" file chooser. - If there are muliple attachments and you choose "Save All", and one of the files already exists in the target directory, the save fails with a file permissions error. It's probably better to append a numerical suffix to any files that have names that clash with files already in the directory, the same as browsers do with downloaded files. Bug 312087 describes a dialog that could be added to show what the attachment was actually saved as. - The file chooser for "Save All" seems to open in the parent directory of whatever it was displaying each time it is opened. So I choose /home/luke/Documents, then the next time it is opened it shows /home/luke, then next time it shows /home.
Additionally, "> No Attachment [Save All]" wastes space in the headers of a message when there are no attachments. As it is, with a 1024x768 screen, you can't see much of a message body when half your vertical space is displaying the message list and half is displaying the current message. Probably the attachment icons only need to be shown if there are actually attachments on a message.
Well, i didnt realize to hide the widgets when there are no attachments, instead of disabling it. I can patch it, but since we are in UI Freeze, ill fix it next release. Ill fix the save folder problem as well. Well the mouse wheel issue, i would love to fix it up and im working on it. Again the dialog to be shown at the end, ill add in the next release.
Additionally, attachments are now listed at the top and at the bottom of the email. It's probably better to have them in one place only. However some attachments have "suggest display of attachment" set, in particular images, but whether or not that's set it's nice to be able to show the image attachment in the body of the image without having to save or open the attachment... How would this work with attachments being at the top now? This is a slightly tricky UI design issue.
Luke, i understand the duplication of the issue. But the point is that, this is the way to go, and the current approach betters this with the mime tree display structure. Im working on it. Also this helps users to DnD, save all etc. About the images stuff. Thatz not right :-). It is not standard. Lets not break it. When some one says not to display automatically, why should we show automatically? :-)
My point was that UI space is wasted by showing attachments twice, in two different places. It also violates the spatial principle, by having two views of the same data. It can also confuse users, who may wonder if the file has been attached twice, and what the difference is between the attachment at the top and the attachment at the bottom. Ultimately they may save both attachments and open them both to see what the difference is between them. My other point was not that all images should be displayed by default, but if there is only one display of attachments, and it's at the top, how will images be viewed within the message body? The little icon view pane is not currently big enough for that. If scrollbars are added or its size is increased, it may work, but you'll need a UI for expanding/contracting images if only thumbnails are shown in the icon list. Don't get me wrong, I think showing attachments at the top is a great improvement, and I agree it's the "way to go". It just presents UI problems in enabling the functionality that was there before for images. Having said that, images and text are the only things you could view in-line before, maybe just make it so that they have to be opened in another program just like everything else. Images can still be thumbnailed.
Yeah luke, i understand the duplication and we should find a way out in future.
the duplication issue is also covered by bug 312413
The part about multiple attachments and its naming is in bug #494425 (there's a patch for it)
Bumping version to a stable release.
Patch mentioned in comment#8 had been committed long back.
I'm closing this because I believe all the issues here have been addressed in the attachment UI rewrite in 2.27.1. That is, except the duplicate attachment view issue which is a WONTFIX. > - The mouse wheel doesn't work while the mouse is over the expanded > attachment "icon view". Presumably this is because if there are enough > attachments, the icon view would include a scrollbar. It's probably better > to just always expand the icon view to take up as much space as it needs to > show all attachment icons, for two reasons: > (1) scroll-pane-inside-a-scroll-pane is never really intuitive; and (2) if > you're using the mouse wheel to scroll down your message, it stops when the > cursor is over the attachment pane. Agreed, and this is exactly what it does now. The top attachment view expands to take up as much space as it needs. > - "Save All" should probably just say "Save" when there is one attachment, > and open the Save As file chooser rather than the "Select a directory" file > chooser. This has been fixed for awhile now. > - If there are muliple attachments and you choose "Save All", and one of > the files already exists in the target directory, the save fails with a > file permissions error. It's probably better to append a numerical suffix > to any files that have names that clash with files already in the directory, > the same as browsers do with downloaded files. Bug 312087 describes a > dialog that could be added to show what the attachment was actually saved as. Again, that's exactly what it does now. > - The file chooser for "Save All" seems to open in the parent directory of > whatever it was displaying each time it is opened. So I choose > /home/luke/Documents, then the next time it is opened it shows /home/luke, > then next time it shows /home. Seems to have been fixed for awhile. Retested in 2.27.1 and confirmed it still works properly. > Additionally, "> No Attachment [Save All]" wastes space in the headers > of a message when there are no attachments. As it is, with a 1024x768 > screen, you can't see much of a message body when half your vertical > space is displaying the message list and half is displaying the current > message. Probably the attachment icons only need to be shown if there > are actually attachments on a message. Srini fixed this awhile back.