On behalf of Sapito B.V. I would also like to offer this second patch. This patch will implement thumbnail support for most popular image formats, to be enabled in the [filetree] filter. Thumbnails will be stored in a subdirectory .thumb, and have the same filename, format and extension as the original file. These thumbnails will be generated "on the fly", unless it already exists. This allows for mass-generation by third party tools.
This patch applies on top of the patch that adds a download manager. Due to extension of hook_menu (previously undefined), it will likely not apply cleanly on GIT without this download manager patch.
Tested on IE8, Firefox 4/5/6 and Google Chrome 11.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 0001-Drupal-Filetree-Add-thumbnail-support-v2.patch | 13.94 KB | RSpliet |
| #6 | 1258442_6_Filetree_thumbnail_support.patch | 8.7 KB | johnv |
| #3 | thumb.png | 25.89 KB | RSpliet |
| 0002-Drupal-Filetree-Add-thumbnail-support.patch | 11.86 KB | RSpliet |
Comments
Comment #1
joelstein commentedIf I were to give this any consideration, we'd have to use Drupal's image toolkits.
Still, I don't understand what you're trying to accomplish. Can you attach a screenshot of this in action?
It sounds like this is something which could better be accomplished with other modules. File Tree isn't for these specific workflows; it just displays files to the screen.
Comment #2
joelstein commentedComment #3
RSpliet commentedWell, a little more explanation about the code then:
It defines a new page whose sole purpose is to serve a thumbnail based on the passed URL. To do so, it checks the .thumb directory as explained. If it doesn't exist (or it's outdated), it attempts to create one.
The page is accessed when hovering the mouse over an image in the filetree. The result is as attached. Simple, but (perhaps) a nice way to show files contents without downloading the entire file.
As for the image toolkit, it indeed seems useful. Pardon me for being a PHP developer over a fully experienced Drupal developer. If you now see the use of this feature and intend to bring it upstream (which is optional in any way and disabled by default) I will attempt to rewrite it to use the Drupal image toolkit.
Comment #4
RSpliet commentedComment #5
RSpliet commentedJoelstein: It is rather unfortunate that I did not hear from you in the past month. Showing (and creating) thumbnails seems like a useful feature for a file tree.
I just looked into Drupal's image toolkit, and it addresses all problems but one: It does not let me see what file types (and/or extensions) are supported by the current installation. A quick peek at the code reveals that right now (where GD is directly invoked) there are checks in place only to show a thumbnail overlay to the user if the file format is recognized as an image and resizable by GD. Installations with GD in place, but no GIF support compiled in will therefore only show the overlay for JPEG, BMP and PNG images. Ideally the Image Toolkit API would provide for a hook that returns the image types supported. This would even allow having complementary engines for different file formats.
So far for the slightly off topic dreaming: I feel the current patch can not cleanly be implemented in the Drupal image toolkit until there is a way to determine the supported file types. If there is a clean way, please inform me. First however I would like to hear if it is worth my effort.
Comment #6
johnvHere's a cleaner patch, which also includes #1313532: Admin settings page .
P.S. The following issue also provides thumbnail support #1309790: Improvements on filetree.
Comment #7
RSpliet commentedAttached patch invalidates patch as referred to by johnv. This work includes (hopefully, but untested) fixes for Windows based machines and setups with clean urls turned on (again, untested... unfortunately I do not possess a Windows server). In addition some logging is done to aid the website maintainer in finding problems with thumbnails not being created. Furthermore a little directive is put in the help of this module and many white-space errors are fixed, so that this patch now cleanly applies on git. It does require the private file downloader patch in #1185198: Private Files not being retrieved comment 13 to be able to apply this patch.