Maybe the shape of the icon should indicate the type of item. Many applications use diamond-shaped icons, while documents are rectangles, often with the top right corner turned down. That's a nice convention.Snowy_River said:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Response to Trojan Warning
- Thread starter MacRumors
- Start date
- Sort by reaction score
Doctor Q said:
The only problem with this is that it would have to be a forced form constraint. Otherwise older applications would not conform to this convention, and it would therefore become useless. And how would the Finder handle a rectangular application icon? Hmm...
By putting it within a larger (or same-size but scaled) diamond-shaped border.Snowy_River said:
Doctor Q said:
Yeah, that could work. To place a square icon into a diamond icon that fits into the current 128x128 square icon, the scaled square icon in the diamond could only be 64x64. So, this would be less than ideal. I think that I still prefer the idea of placing a mini-icon superimposed over the application icon.
dontmakemehurtu said:
It it wasn't encoded in some way, then it was most likely rendered harmless. Gnutella networks don't know anything about resource forks, therefore all the information necessary for the application to actually launch should have been stripped of (and in fact, it probably should have looked exactly like an mp3 to the finder, except that it wouldn't play as if it were corrupt).
dontmakemehurtu said:
It would have been much more useful if you had given us screen shots of the get info panel that you did see. Given the method that you obtained the file with, I find it hard to think that this trojan could have even been executable or identified as an application instead of as an mp3. The only way I can think of this, is if Acquisition can automatically decode mac-binary of binhexed files and does this transparently to the user.
dontmakemehurtu said:
This sounds like one of two things. Either a hoax, or a completely different situation.
Hoax:
1) I've never heard of gnutella networks misreporting file size.
2) These networks don't preserve resource forks, so if the file wasn't properly encoded it couldn't be a version of this trojan.
3) This trojan can be opened through the open dialog box in QT.
Something else:
1) If the file was not completely downloaded, this would explain why the file size was smaller than originally reported.
2) If the file was not completely downloaded, it could easily have been corrupted, and that would explain why QT couldn't open the file.
3) If the file was corrupted, then the Finder's attempt to provide all of the information that's shown in the Get Info pallet could have fallen short, resulting in a panel that "looked more like one for an app than one for an MP3"
Just my thoughts...
Rincewind42 said:
But gnutella is a peer-to-peer network. If you download from another mac user, the file never passes through a computer that doesn't support resource forks. I don't know much about how gnutella works, but since the file could be transferred directly from another mac, I think it is possible that the file could get through with the resource fork intact.
coolsoldier said:
That is only true if the client on both machines supports resource forks, and has the same protocol in place for identifying Mac clients and send them resource forks when requested. AFAIK no p2p client does this. Specifically, almost all of the gnutella clients I know of are written in java at their core, and they do nothing special to preserve resource forks (because they are designed to be cross platform rather than to be mac savvy).