71656 - Create preview icons for downloaded images

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Andrew Thompson]

At least Macs, and I believe Windows of the 98/2000 or newer vintage support 
preview icons for images. Actually some Mac image formats have explicit support 
for a preview image, *and* a preview icon ... i.e. the icon used for the image on 
disk is a mini version of the image.

Since I implemented support for creating Mac icons, this should be relatively 
easy, once that's checked in. Will set depends.

One issue: its really really inefficient for tiny images. This means we might 
want a pref... but prefs for esosteric things are evil. So maybe a pref with no 
user interface.

Comment 1

[Matthew T (active 1999-2002)]

I think Windows generates the preview icons itself by actually reading the 
file, right? (Timeless?) But for Mac OS, we need to generate the icons when the 
file is created.

The `really really inefficient' thing isn't a problem for tiny images so much 
(we'd scale them up just like we scale bigger images down), but for images 
which have an extreme aspect ratio -- where scaling the width/height to 32 
pixels makes the the height/width scale to some absurdly small figure. E.g. in 
Internet Explorer, if I drag the mozilla.org banner (quite a large image) to 
the desktop, the resulting icon is about 4 pixels high, because the picture is 
so wide in comparison with its height.

Now, there are two approaches we can take to this problem.

(1) Don't worry about it, since the filename can be
    clicked/dragged/double-clicked as well as the icon, so it doesn't *really*
    matter if the icon itself is hard to click. However this wouldn't solve the
    problem of the picture being hard to recognize -- especially in the OS X
    Dock, which doesn't show filenames along with the icons.

(2) Crop the part of the image we preview, so that the aspect ratio is never
    more extreme than 1:4 or 4:1 (so the icon is always at least 8 pixels thick
    in its smallest direction). The downside is that we'd no longer be able to
    use the aspect ratio itself as a visual guide to which icon was which
    picture.

I think (2) is preferable, though obviously it would require a bit more work. 
What do my fellow Mac-heads think?

Comment 2

[Simon Fraser [no longer active]]

geez, don't we have more important bugs to work on? We're not a PhotoShop. If Mac 
people want previews, they can use one of the shareware apps for making such.

Comment 3

[Adam]

I also don't think this is a good idea. There are a lot of things that have to
be considered, and I don't think it's worth the effort. Are you going to create
standard icons (which will require at least 3 resources), new icons (icns) or
huge 48x48 icons and 128x128 icons? Are they going to be dog-eared or not? Are
they going to have borders or not? Standard 256-color icons or 24- or 32-bit
icons? If you only create new 'icns' icons, they won't be visible if you
transfer the files to a PC running an older OS. All this is a waste of space
(both in the size of the file, and in any interface additions you have to
include to accomodate this feature). Also, in Mac OS X, anything other than
128x128 photo-realistic (32-bit) icons is going to look butt-ugly. And resource
forks are unnecessary. And the Finder will create custom previews (although not
icons) when in column view. It's not very cross-platform, and I'd prefer that
files I download be (more or less) exactly the same as they are on the server.
I'm downloading the images, not creating them. The internet is (or at least was)
platform-agnostic. The files Mozilla creates should be as well (at least as much
as is possible), especially since "XP" is such a major theme in the project.

If, however, somebody decides to go ahead with it, I prefer *no* dog-eared,
black bordered, 32-bit Mac OS 8.5+ ('icns') icons. (Note that you can use
QuickTime to accomplish this.) I would be very unhappy if all of my image files
start downloading with dog-eared, no bordered, 8-bit nasty icons, with no
preference to disable this behavior.

I agree with Simon, however. Point users to the download page for
GraphicConverter if they start enquiring about this feature.

Comment 4

[Andrew Thompson]

Woah, I had no idea this would be controversial.

Stylistically, we should do whatever Grapahic Converter and other Mac drawing 
apps do. Yeah, it has some problems, but there's no ideal solution so go for the 
familiar solution people will already recognise.

Also, there seems to be some confusion between a QuickTime preview and the icon 
being a preview. These are 2 seperate things. A Quicktime Preview appears in the 
Open dialog box (and now the Finder in column view) for an image. An icon preview 
is just an icon for the file which looks like a mini version of the image.

This probably is something that is worthy of a UI preference (not often I say 
that) because it is inefficient for small images, but it could really please a 
lot of people.

I don't see how this effects the cross-platform-ness of an image file at all. 
Nothing that's placed in the resource fork is essential to the image. The data 
fork will transfer to a PC/Unix machine just fine. I wasn't aware we need to 
limit support for Mac features because a file stored on a remote server doesn't 
already have an icon. Should we not set creator and type codes for a downloaded 
file because the FTP server they came from is running Unix?

I'm not being sarcastic to offend. I'm sleepy and I can't find a more eloquent 
way to make my point right now.

I also find it strange that 32x32, 8 bit icons are now considered "butt ugly". I 
have lots of them on my drives, for images and all sorts of things. Its an icon, 
it just needs to be representative. A lot of images aren't 24/32bit anyway. 
Populating an icns resource or traditional icon resources isn't difficult because 
I already wrote the code to do it, its just not checked in. We can do any 
combination.

I want this, but its pretty low priority for me.

Comment 5

[Matthew T (active 1999-2002)]

Okay. I'm probably completely the wrong person to say this, but ... It's a bad 
look to discourage someone from making an improvement to Mozilla, or from 
filing a valid bug, no matter how unimportant that improvement or bug may seem.

And if we want to be as cross-platform as possible, should we also rip out all 
support we have for Internet Config, or the Appearance Manager, or the Classic 
theme? I thought not.

As lordpixel said, the majority of the code for this will be included in 
Mozilla anyway, for things like giving the `Move to' submenu the proper folder 
icons, and having the right proxy icons, and stuff like that.

In the absence of a `Non-XP Apps' Bugzilla component, moving to Networking:File 
and reassigning to lordpixel.

Comment 6

[Adam]

My only concern here is that what's desirable to one person may not be desirable
to another, and there's lots of ways to make a custom icon. But as long as
there's a preference (with a user interface, possibly Advanced->Images->When
Saving Images - there's plenty of room there for now) so that I can turn this
off, I'm sure it'd be a feature that would make some users happy.

Trust me, I had no intention of discouraging others from filing bugs or adding
features. I have a tendency to over-react when I hear things like "pref with no
user interface." If the work's done, I say push to get that checked in, but
leave it off until a suitable prefs item can be added (as I said earlier,
there's lots of room in the Images pane, and I don't think this feature is
esoteric enough to warrant not including a UI for the prefs).

Comment 7

[benc]

-> file-handling

In general, I think we should try to implemlent OS specific features when
possible... otherwise we give all power users a feeling of neglect on the
platform of their preference (see comments about bugs where .url files are not
working in windows...)

Comment 8

[benc]

Aren't there MacOS applications that do preview icons (of all types mentioned 
above)? If they support a target folder, it would easier to find ways of 
integrating them into our downloads.

Mac people inevitably want a lot of customization and robustness to features 
like this, it would be better for all parties involved to utilize existing 
popular software rather than bolting it onto our not-so-lean-and-mean 
"browser".

Comment 9

[Matthew T (active 1999-2002)]

Yes, there are apps which can make useful icons for image files, but AFAIK none 
of them are free. No, I shouldn't have to save a file into a specific folder 
just for it to get a useful icon, that would be a PITA. And no, Mac people 
usually prefer that things Just Work than that they be infinitely customizable 
(compare any control panel in Mac OS with the equivalent in Windows).

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.