Well, THAT's a good and sense making feature, my compliments.
Two comments:
- It would IMHO be a good idea to indicate in some way that the images
displayed below the message are just thumbnails. I wasn't aware of this feature yesterday evening, received a mail with some pics, and was surprised that the sender did shrink them to such a small size (which I would even have preferred)... ;)
- Is it planned to provide a second link (next to the "Download" link),
which simply displays the image - full size or fit-to-screen, and probably in a new window - within Roundcube? We know from the past that Roundcube can do that. ;-) That would at least be much more convenient rather than downloading the image and then loading it into the local app being associated to this file type on this particular system - if such an app is available at all (think of Internet Cafés and such).
If 2) should not be planned yet, this should change. ;)
Thanks again and regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 11.11.2012 14:11, schrieb GitHub:
Branch: refs/heads/master Home: https://github.com/roundcube/roundcubemail Commit: 03149131f754dd122f8707fbfc9e7ff47e9d6524
https://github.com/roundcube/roundcubemail/commit/03149131f754dd122f8707fbfc... Author: Thomas Bruederli thomas@roundcube.net Date: 2012-11-10 (Sat, 10 Nov 2012)
Changed paths: M config/main.inc.php.dist M program/include/html.php M program/include/rcube_image.php M program/steps/mail/func.inc M program/steps/mail/get.inc M skins/classic/mail.css M skins/larry/mail.css M skins/larry/templates/messagepart.html
Log Message:
New feature: display attached images as thumbnails below message body
Commit: e43dcb0df3e7ea6c05a8c1473b0da7834d5e39d9
https://github.com/roundcube/roundcubemail/commit/e43dcb0df3e7ea6c05a8c1473b... Author: Thomas Bruederli thomas@roundcube.net Date: 2012-11-11 (Sun, 11 Nov 2012)
Changed paths: M CHANGELOG M installer/rcube_install.php M plugins/help/package.xml M plugins/help/skins/larry/help.css M plugins/help/skins/larry/templates/help.html M program/steps/mail/func.inc
Log Message:
Merge branch 'master' of github.com:roundcube/roundcubemail
Compare: https://github.com/roundcube/roundcubemail/compare/71649445a0b8...e43dcb0df3...
Roundcube SVN commits mailing list svn@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/svn
Michael Heydekamp wrote:
Well, THAT's a good and sense making feature, my compliments.
Two comments:
- It would IMHO be a good idea to indicate in some way that the images
displayed below the message are just thumbnails. I wasn't aware of this feature yesterday evening, received a mail with some pics, and was surprised that the sender did shrink them to such a small size (which I would even have preferred)... ;)
OK, I thought it's somehow obvious that images of this size are thumbnails... Any concrete suggestions how to visualize that better?
- Is it planned to provide a second link (next to the "Download" link),
which simply displays the image - full size or fit-to-screen, and probably in a new window - within Roundcube? We know from the past that Roundcube can do that. ;-) That would at least be much more convenient rather than downloading the image and then loading it into the local app being associated to this file type on this particular system - if such an app is available at all (think of Internet Cafés and such).
You can click on the thumbnail itself to open up the full size image. Mabye an additional link "Show" next to "Download" would fix this.
If 2) should not be planned yet, this should change. ;)
And you can still open the image by clicking the file name in the regular attachment listing. This still does and has always been opening images in a new window.
Regards, Thomas
On 11/14/2012 09:32 AM, Thomas Bruederli wrote:
- It would IMHO be a good idea to indicate in some way that the images
displayed below the message are just thumbnails. I wasn't aware of this feature yesterday evening, received a mail with some pics, and was surprised that the sender did shrink them to such a small size (which I would even have preferred)... ;)
OK, I thought it's somehow obvious that images of this size are thumbnails... Any concrete suggestions how to visualize that better?
This doesn't look good when there are more images with different size e.g. pictures and icons. Maybe we should display smaller thumbnails. Thumbnails should be the same size, which means very small images would be centered and border would be added (to the thumbnail object not image). Maybe we don't need any text on them. They could be in one horizontal line (with scrollbar or some smart widget) or in many lines. Then click on thumbnail would open popup/window with the image.
Of course integration with some image gallery e.g. http://galleria.io/ might be a good addition.
Am 14.11.2012 09:32, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Well, THAT's a good and sense making feature, my compliments.
Two comments:
- It would IMHO be a good idea to indicate in some way that the images
displayed below the message are just thumbnails. I wasn't aware of this feature yesterday evening, received a mail with some pics, and was surprised that the sender did shrink them to such a small size (which I would even have preferred)... ;)
OK, I thought it's somehow obvious that images of this size are thumbnails... Any concrete suggestions how to visualize that better?
Just displaying the text "Thumbnail" (well, how would you translate this into German ;) ?) somewhere above/below the picture...? In contradiction to A.L.E.C's post, the size is OK to me, as in most cases this relatively large thumbnail size would often not even lead me to display/load the picture in full size at all. This is pretty convenient, IMHO.
- Is it planned to provide a second link (next to the "Download" link),
which simply displays the image - full size or fit-to-screen, and probably in a new window - within Roundcube? We know from the past that Roundcube can do that. ;-) That would at least be much more convenient rather than downloading the image and then loading it into the local app being associated to this file type on this particular system - if such an app is available at all (think of Internet Cafés and such).
You can click on the thumbnail itself to open up the full size image. Mabye an additional link "Show" next to "Download" would fix this.
Probably. It depends what the link exactly would do - show it WITHIN Roundcube (i.e. the browser) or launch a local app?
At least it currently doesn't work the way you're describing in IE8/Win7. I can click on the thumbnail, but instead of opening up the full size image within Roundcube or the browser, I'm getting a dialogue "Möchten Sie diese Datei öffnen oder speichern?" ("Do you want to open or save this file?"). If I click on "Öffnen" (= Open), then the image is loaded into the "Windows-Fotoanzeige" - and this is exactly what I would like to avoid, as this is an app on the local machine.
Is this behaviour different elsewhere...?
And you can still open the image by clicking the file name in the regular attachment listing. This still does and has always been opening images in a new window.
Yes and no. It does bring up exactly the same dialogue as described above, so a local app will afterwards be launched if I click on "Open".
I never saw that clicking on an image attachment does show it WITHOUT loading it into a local app.
But what I saw is, that RC can display it in full size below the message, before the thumbnail feature was invented. So it should somehow also be possible to display it within RC/browser when being clicked (be it on the thumbnail itself or on the attachment listing).
But anyway, good job and thanks again!
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Michael Heydekamp wrote:
Am 14.11.2012 09:32, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Well, THAT's a good and sense making feature, my compliments.
Two comments:
- It would IMHO be a good idea to indicate in some way that the images
displayed below the message are just thumbnails. I wasn't aware of this feature yesterday evening, received a mail with some pics, and was surprised that the sender did shrink them to such a small size (which I would even have preferred)... ;)
OK, I thought it's somehow obvious that images of this size are thumbnails... Any concrete suggestions how to visualize that better?
Just displaying the text "Thumbnail" (well, how would you translate this into German ;) ?) somewhere above/below the picture...? In contradiction to A.L.E.C's post, the size is OK to me, as in most cases this relatively large thumbnail size would often not even lead me to display/load the picture in full size at all. This is pretty convenient, IMHO.
First of all, the size of the thumbnails is configurable through the 'image_thumbnail_size' option.
- Is it planned to provide a second link (next to the "Download" link),
which simply displays the image - full size or fit-to-screen, and probably in a new window - within Roundcube? We know from the past that Roundcube can do that. ;-) That would at least be much more convenient rather than downloading the image and then loading it into the local app being associated to this file type on this particular system - if such an app is available at all (think of Internet Cafés and such).
You can click on the thumbnail itself to open up the full size image. Mabye an additional link "Show" next to "Download" would fix this.
And I just added these explicit links to "Show" an image attachments right next to the "Download" links.
Probably. It depends what the link exactly would do - show it WITHIN Roundcube (i.e. the browser) or launch a local app?
At least it currently doesn't work the way you're describing in IE8/Win7. I can click on the thumbnail, but instead of opening up the full size image within Roundcube or the browser, I'm getting a dialogue "Möchten Sie diese Datei öffnen oder speichern?" ("Do you want to open or save this file?"). If I click on "Öffnen" (= Open), then the image is loaded into the "Windows-Fotoanzeige" - and this is exactly what I would like to avoid, as this is an app on the local machine.
By default, Roundcube opens attachment types known that browsers can display them (e.g. image/jpeg, text/plain, etc.) in a new browser window but doesn't send them to be downloaded. The default list of mimetypes can be overwritten in you local config. Check option 'client_mimetypes'. If it's set to null, then the default list applies.
Is this behaviour different elsewhere...?
Yes, in my browser :-)
But I had a closer look at it with IE9 on Win7 and indeed found out a totally weird behavior there, which caused all attachments to be downloaded directly: the list of supported mimetypes, which is passed to the browser as array mimetypes:["text/plain",...] is, for some reason only Microsoft knows, treated as an object here. So .indexOf() didn't work as expected.
That's really a bummer! I didn't find out why IE randomly treats array syntax as Object instead of Array. I workarounded it in https://github.com/roundcube/roundcubemail/commit/54cc75f28d75d01eb10c0be51e...
And you can still open the image by clicking the file name in the regular attachment listing. This still does and has always been opening images in a new window.
Yes and no. It does bring up exactly the same dialogue as described above, so a local app will afterwards be launched if I click on "Open".
Right, because it's exactly the same procedure called. And that also applies for the new "Show" links.
I never saw that clicking on an image attachment does show it WITHOUT loading it into a local app.
That should be solved now with the fix for IE described above.
But anyway, good job and thanks again!
Thanks a lot!
Regards, Thomas
Am 17.11.2012 18:13, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Just displaying the text "Thumbnail" (well, how would you translate this into German ;) ?) somewhere above/below the picture...? In contradiction to A.L.E.C's post, the size is OK to me, as in most cases this relatively large thumbnail size would often not even lead me to display/load the picture in full size at all. This is pretty convenient, IMHO.
First of all, the size of the thumbnails is configurable through the 'image_thumbnail_size' option.
Ah, this I didn't know.
- Is it planned to provide a second link (next to the "Download" link),
which simply displays the image - full size or fit-to-screen, and probably in a new window - within Roundcube? We know from the past that Roundcube can do that. ;-) That would at least be much more convenient rather than downloading the image and then loading it into the local app being associated to this file type on this particular system - if such an app is available at all (think of Internet Cafés and such).
You can click on the thumbnail itself to open up the full size image. Mabye an additional link "Show" next to "Download" would fix this.
And I just added these explicit links to "Show" an image attachments right next to the "Download" links.
Great, thanks.
At least it currently doesn't work the way you're describing in IE8/Win7. I can click on the thumbnail, but instead of opening up the full size image within Roundcube or the browser, I'm getting a dialogue "Möchten Sie diese Datei öffnen oder speichern?" ("Do you want to open or save this file?"). If I click on "Öffnen" (= Open), then the image is loaded into the "Windows-Fotoanzeige" - and this is exactly what I would like to avoid, as this is an app on the local machine.
[...]
But I had a closer look at it with IE9 on Win7 and indeed found out a totally weird behavior there, which caused all attachments to be downloaded directly: the list of supported mimetypes, which is passed to the browser as array mimetypes:["text/plain",...] is, for some reason only Microsoft knows, treated as an object here. So .indexOf() didn't work as expected.
That's really a bummer! I didn't find out why IE randomly treats array syntax as Object instead of Array. I workarounded it in https://github.com/roundcube/roundcubemail/commit/54cc75f28d75d01eb10c0be51e...
I just saw it in the svn-list. This again proves how important testing is.
I will test it this night or tomorrow. We are automatically pulling the latest git version between 1h and 2h.
Again, great that you found (and fixed) this weird behaviour of IE.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 17.11.2012 18:42, schrieb Michael Heydekamp:
Am 17.11.2012 18:13, schrieb Thomas Bruederli:
But I had a closer look at it with IE9 on Win7 and indeed found out a totally weird behavior there, which caused all attachments to be downloaded directly: the list of supported mimetypes, which is passed to the browser as array mimetypes:["text/plain",...] is, for some reason only Microsoft knows, treated as an object here. So .indexOf() didn't work as expected.
That's really a bummer! I didn't find out why IE randomly treats array syntax as Object instead of Array. I workarounded it in https://github.com/roundcube/roundcubemail/commit/54cc75f28d75d01eb10c0be51e...
I just saw it in the svn-list. This again proves how important testing is.
I will test it this night or tomorrow. We are automatically pulling the latest git version between 1h and 2h.
Strange, after this fix I can't see any images anymore below the mail (neither thumbnails nor the full images) with Win7/IE8.
'image_thumbnail_size' is set to 240, 'inline_images' to true.
Hmmm... Any idea?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Please disregard the message below. I was looking at wrong mails which did not have any attachments at all.
Everything is working at expected. :) (Well, not everything, see below!)
Just the string "Show" should be localized, as "Show" and "Herunterladen" right next to each other do look a bit strange. ;)
Argh... Somewhat later, I found another message (the one with the Classic and Larry screenshots I posted to this list at 20:29 on Nov 17th) where I do neither see a link "Show" at all, nor that a click on the thumbnail would display the screenshot within the browser (it gets downloaded instead). Now what the heck is this again...?
'client_mimetype' is indeed set to NULL here - but why does it work then with some messages, and with others not? Filling this setting with a comma-separated list of MIME types does have nil effect.
Last but not least: It should be clarified in main.inc.php, if the size of 'image_thumbnail_size' is meant to define the height or the width of the thumbnail.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 18.11.2012 01:49, schrieb Michael Heydekamp:
Am 17.11.2012 18:42, schrieb Michael Heydekamp:
Am 17.11.2012 18:13, schrieb Thomas Bruederli:
But I had a closer look at it with IE9 on Win7 and indeed found out a totally weird behavior there, which caused all attachments to be downloaded directly: the list of supported mimetypes, which is passed to the browser as array mimetypes:["text/plain",...] is, for some reason only Microsoft knows, treated as an object here. So .indexOf() didn't work as expected.
That's really a bummer! I didn't find out why IE randomly treats array syntax as Object instead of Array. I workarounded it in https://github.com/roundcube/roundcubemail/commit/54cc75f28d75d01eb10c0be51e...
I just saw it in the svn-list. This again proves how important testing is.
I will test it this night or tomorrow. We are automatically pulling the latest git version between 1h and 2h.
Strange, after this fix I can't see any images anymore below the mail (neither thumbnails nor the full images) with Win7/IE8.
'image_thumbnail_size' is set to 240, 'inline_images' to true.
Hmmm... Any idea?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Am 18.11.2012 02:34, schrieb Michael Heydekamp:
Argh... Somewhat later, I found another message (the one with the Classic and Larry screenshots I posted to this list at 20:29 on Nov 17th) where I do neither see a link "Show" at all, nor that a click on the thumbnail would display the screenshot within the browser (it gets downloaded instead). Now what the heck is this again...?
Even more funny: The link "Show" does not appear in all messages with image attachments which have been produced by ... tadaa ... Roundcube. The same applies to the function of displaying them in a separate browser window upon clicking on the thumbnail.
If messages are needed, please let me know.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Michael Heydekamp wrote:
Am 18.11.2012 02:34, schrieb Michael Heydekamp:
Argh... Somewhat later, I found another message (the one with the Classic and Larry screenshots I posted to this list at 20:29 on Nov 17th) where I do neither see a link "Show" at all, nor that a click on the thumbnail would display the screenshot within the browser (it gets downloaded instead). Now what the heck is this again...?
Even more funny: The link "Show" does not appear in all messages with image attachments which have been produced by ... tadaa ... Roundcube. The same applies to the function of displaying them in a separate browser window upon clicking on the thumbnail.
I see one of your messages to the list where all the image attachments having Content-Type: application/octet-stream instead of image/jpeg or whatever. This is also the reason why those attachment are not detected as images and thus no thumbnails are displayed and no inline viewing is offered.
Roundcube tries to detect the mimetypes of uploaded attachment files and this again depends on your server's environment and configuration:
First, there is a mapping file in <roundcubedir>/config/mimetypes.php for simple filename extension to mimetype mapping.
Second, check the 'mime_magic' option which should point to a valid mime description file on your server which is used by PHP fileinfo extension (http://www.php.net/manual/en/book.fileinfo.php).
And third, Roundcube tries mime_content_type() which again is a function provided by PHP.
An easy fix is to add entries for image file extensions to your local confog/mimetypes.php file. But try to fix the 'mime_magic' path first.
~Thomas
Am 18.11.2012 15:36, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Even more funny: The link "Show" does not appear in all messages with image attachments which have been produced by ... tadaa ... Roundcube. The same applies to the function of displaying them in a separate browser window upon clicking on the thumbnail.
I see one of your messages to the list where all the image attachments having Content-Type: application/octet-stream instead of image/jpeg or whatever.
That's true, but that can't be the cause of the problem, IMO. Because:
This is also the reason why those attachment are not detected as images and thus no thumbnails are displayed and no inline viewing is offered.
Then you misunderstood: They ARE detected as images by Roundcube, as the thumbnails ARE being displayed (and as in 0.8.4 the images are displayed in full size below the message preview).
It's just the link "Show" that is missing if "application/octet-stream" is declared in the Content-Type: header of image attachments! Plus that clciking on the thumbnail does download the image rather than viewing it.
But if they are already detected as images apparently, why not provide the "Show" link then?
Roundcube tries to detect the mimetypes of uploaded attachment files and this again depends on your server's environment and configuration:
First, there is a mapping file in <roundcubedir>/config/mimetypes.php for simple filename extension to mimetype mapping.
The file is there, but it doesn't contain any of the typical image extensions. We just took it 'as is', means we didn't change anything and are using the default config of Roundcube. Did we do wrong...?
From my point of view, if Roundcube should really rely on a different
Content-Type for image attachments (which I doubt, see above), then the appropriate extensions and Content-Type declarations should be added to this file - but by default.
Second, check the 'mime_magic' option which should point to a valid mime description file on your server which is used by PHP fileinfo extension (http://www.php.net/manual/en/book.fileinfo.php).
And third, Roundcube tries mime_content_type() which again is a function provided by PHP.
An easy fix is to add entries for image file extensions to your local confog/mimetypes.php file. But try to fix the 'mime_magic' path first.
This I will of course check.
But again: The detection should not (und IMO does not) rely on a certain Content-Type declaration. Otherwise Roundcube wouldn't even display the thumbnails.
Plus that any change for future outgoing messages wouldn't help for already existing messages in the INBOX - which may have been produced by any MUA.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Michael Heydekamp wrote:
Am 18.11.2012 15:36, schrieb Thomas Bruederli:
Michael Heydekamp wrote:
Even more funny: The link "Show" does not appear in all messages with image attachments which have been produced by ... tadaa ... Roundcube. The same applies to the function of displaying them in a separate browser window upon clicking on the thumbnail.
I see one of your messages to the list where all the image attachments having Content-Type: application/octet-stream instead of image/jpeg or whatever.
[...]
But again: The detection should not (und IMO does not) rely on a certain Content-Type declaration. Otherwise Roundcube wouldn't even display the thumbnails.
Fixed in https://github.com/roundcube/roundcubemail/commit/b81e7e91a958cb7432ef3be67d...
~Thomas
Thomas Bruederli wrote:
I see one of your messages to the list where all the image attachments having Content-Type: application/octet-stream instead of image/jpeg or whatever. This is also the reason why those attachment are not detected as images and thus no thumbnails are displayed and no inline viewing is offered.
Roundcube tries to detect the mimetypes of uploaded attachment files and this again depends on your server's environment and configuration:
First, there is a mapping file in <roundcubedir>/config/mimetypes.php for simple filename extension to mimetype mapping.
Second, check the 'mime_magic' option which should point to a valid mime description file on your server which is used by PHP fileinfo extension (http://www.php.net/manual/en/book.fileinfo.php).
After reading through the docs and some forum entries, it seems best if you set the 'mime_magic' config option in Roundcube to null. This will let the fileinfo extension use its default mimetype config file.
For debugging purposes, check your error logs for messages like this: PHP Warning: finfo_open(): Failed to load magic database ...
That of course assumes that your PHP installation includes the fileinfo module.
And third, Roundcube tries mime_content_type() which again is a function provided by PHP.
And fourth, as the ultimate fallback, the mimetype submitted by your browser when uploading the attachment file is used.
An easy fix is to add entries for image file extensions to your local config/mimetypes.php file. But try to fix the 'mime_magic' path first.
I'd consider this the last option because usually filename extensions are not very reliable and can easily be faked.
~Thomas
Am 27.11.2012 16:43, schrieb Thomas Bruederli:
After reading through the docs and some forum entries, it seems best if you set the 'mime_magic' config option in Roundcube to null. This will let the fileinfo extension use its default mimetype config file.
And now we send Attachments that are pictures as mimetype image/* Thanks.
For debugging purposes, check your error logs for messages like this: PHP Warning: finfo_open(): Failed to load magic database ...
This warning is not in $rc$/logs/error or /var/log/apache2/error.log
Am 17.11.2012 18:42, schrieb Michael Heydekamp:
I will test it this night or tomorrow. We are automatically pulling the latest git version between 1h and 2h.
I setup the cronjob so that it runs at 0:20 every day. Now (after the switchof of daylight saving) I see the response-mail from that cronjob at 23:20 every day.
On 11/17/2012 06:13 PM, Thomas Bruederli wrote:
First of all, the size of the thumbnails is configurable through the 'image_thumbnail_size' option.
Wouldn't be better to set size as percentage of detected screen (or message body element) width?
Am 18.11.2012 14:21, schrieb A.L.E.C:
On 11/17/2012 06:13 PM, Thomas Bruederli wrote:
First of all, the size of the thumbnails is configurable through the 'image_thumbnail_size' option.
Wouldn't be better to set size as percentage of detected screen (or message body element) width?
I second that (the latter being the better option).
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
-
A.L.E.C -
Martin Wodrich -
Michael Heydekamp
-
Thomas Bruederli