GNOME Bugzilla – Bug 498981
ugh... hard to view attachments
Last modified: 2021-05-19 12:14:32 UTC
I typically get messages from my friends that have been forwarded multiple times and so contain lots of junk textual content, but the really interesting content of the message is multiple (sometimes up to 20 or more) images attached to it. In GMail, one would click on "view all images" and see them all in one page. With Evo? First, I need to expand attachments one by one, and if the images are large, each expansion takes seconds, during which of course Evo is hung. But what's worse is that after expanding, the message view is updated to show the beginning of the message. This happens, I assume, because Evo relayouts the entire message. Heck, need to scroll down to where I was. Space bar comes handy, well, not anymore, because of the magic space... Ugh. Why does it have to be so hard to view my attached images :(.
As for the "view all images" part, I think this is a duplicate of bug 271691. As for needing to scroll down again after expanding each image, I'm unable to reproduce this in 2.22.3.1.
I think this will be fixed by the migration to WebKit (which thankfully is not a pipe dream anymore since we have working code in Anjal). The reason is, we'll be packing the attachment widgets differently. With GtkHtml, we embed everything -- headers, body and attachments -- into a single GtkHTML (HTML viewer) widget. Everytime an embeded widget changes, the entire GtkHTML widget has to redraw itself. WebKit doesn't support embedding, so we were forced to rethink the approach. IIUC, what Anjal is doing currently is rendering messages as just a GtkVBox with multiple WebView / GtkImage / whatever widgets packed into it. This eliminates having to redraw the entire message when you expand/collapse an attachment. Makes for a much cleaner implementation, too. Seems obvious, but there's a lot of scaffolding around the old approach. So it's not as easy to switch over as you might think. But with Anjal we now have a working reference implementation, so it -will- happen for Evolution.
I'm still not able to view all images (or also text or other kind of attachments supporting inline view) inline by one click. With respect of scrolling, it's fixed already. I'm setting version to 2.30 and confirming the bug. As there is one for webkit already, then I believe this is just about adding some option somewhere saying "view all attachments inline". I would use both View menu and the popup over the attachment, when there are more than one attachment available for inline viewing, but collapsed. Similar for "Collapse all attachments". Please correct me if I'm wrong.
Hrm, I'm not sure, I would like to know an idea from a usability educated person. Adding "All attachments inline" in a "View" menu would seem strange, probably also with "Hide all inline attachments". Having an option in the popup menu over the respective attachment might work for itself, but who may look there for such an option for all attachments? Not talking about a fact that not all users know about menu option in this place at all. The other option may be to add "View all"/"Hide all" beside "Save all" at the top, but that's at the top, so one may click on it and wonder "what did it do?" when he/she has a large email and this is influencing its end. Thus the question is, where to put "View all inline"/"Hide all inline" options to have them easily foundable for users? Note that I expect having enabled (not only visible) each of them only when it is usable at the moment.
Finally, an opportunity for me to do a usability review of Evolution's attachments UI! Have you guys considered putting the "attachment bar/expander" at the bottom of the mails, expanded by default? There are many reasons why I am suggesting this: - Most mail interfaces do it, including GMail - Currently, you are have the (image) attachments in two different places. From my limited usability testing with non-geeks, this sucks because they don't even notice the expandable thing at the top (or rather, they would never think that thing can be expanded). The whole "click the image icons to expand it" also fails the "intuitiveness test". - Consistency: in the composer mode, the attachments are at the bottom, not top. - "Show all images" is an action that applies to all of them. It should thus be near the "Save all as" button. This would be pretty intuitive if we didn't have the "two places for attachments" problem. This is also what GMail does. - Shouldn't we have small thumbnails (instead of icons) shown by default? This way the user can properly judge if they need to be seen in full-size or not. I think I'll make a mockup, it will make things clearer.
Actually, I have another idea that might work well (in terms of UI; not sure about the performance or implementability). 1- Expand the attachment thing by default, icon view mode 2- Show thumbnails (instead of icons) in icon view mode. Actually not thumbnails. The whole images, but sized down. 3- Provide a slider widget that acts like F-Spot (or PiTiVi's, or OpenOffice's...) zoom widget. Dragging it completely to the right makes the "thumbnails" (images, actually) resize to 100% of the width of the window, and dragging them to the left makes them tiny. With that, you wouldn't really need the bunch of images at the bottom.
(In reply to comment #2) > I think this will be fixed by the migration to WebKit Adding Dan to CC as I'd love to know if Matt is right. :)
Hi, (In reply to comment #7) > (In reply to comment #2) > > I think this will be fixed by the migration to WebKit > > Adding Dan to CC as I'd love to know if Matt is right. :) Hmm, close enough :) I'd rather have the image rendered by WebKit not by GtkImage (mainly because of the auto-resize feature - see bug #649938), so there will probably be some JavaScript magic or so.
Created attachment 207124 [details] mockup How about something like this? The idea in this mockup is to reuse the widgets from the mail composer, but replace the "Add an attachment" button by a "Save as..." button that gets sensitive when one of the items is selected (clicked). When the mouse hovers one of the items, a nice composited overlay (as shown in the mockup) would display the image in a reasonable size (1:1 if possible, otherwise as big as possible with the available space above the icon view). Actually, this composited preview thing could also be used in the composer, not just the "received mail" view.
needs retesting once webkit is in place.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.