Closed Bug 214054 Opened 17 years ago Closed 16 years ago
Firefox should provide icons for associated files and shortcuts
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030720 Mozilla Firebird/0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030720 Mozilla Firebird/0.6 All files that are associated with Firebird are displayed using the main Firebird icon. Firebird should provide an icon for each of these types, Reproducible: Always Steps to Reproduce: 1. 2. 3.
Confirming as a new non-dup RFE. I don't think this really is a bug as such since Mozilla has never done this before, by design.
Severity: trivial → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Granted, but it does creates visual confusion to wetter a icon represents firebird, an html page, etc. So I consider a usability issue/bug
I agree this is a good idea for the future, but not an immediate necessity. The way we provide icons within the source tree is a mess. The icons don't have the same naming scheme for windows, and many other problems. I think giving that some sanity would be something necessary before we ever added any more icons and hook them into code. I'd also like to see more application icons available, and all the association icons should be in a DLL file on windows.
I guess this is not quite a dupe of bug 99380 since that bug is for Seamonkey, right?
It is in the sence that it's the same thing but it's not in the sence firebird icons would be diferent. Since Firebird is going to become the default Mozilla Browser, maybe the mentioned bug should handle both icon sets?
If the implementation would be done differently in both cases (which it might have to be) then its definately not a dupe, and can be done for Firebird and the icons changed later when Firebird becomes Mozilla. That's why I am sorta iffy about whether its a dupe. Someone with more knowledge about what's going on will have to decide.
I'd done this in my icon pack, (see http://deskmod.com/?show=showskin&skin_id=9673) but it apparently never made it into the tree when the app icons were moved in. Let me know (grayrest at grayrest.com) if arvid doesn't want to do the icons, I'll redo mine (the 48x48 is ugly, I'd need to redo that).
Right, because Firebird doesn't yet support different application icons afaik (not 100% sure). Just like for XPFE browser (bug 99380), this shouldn't be hacked in like everything else. In fact, the mess of the way the icons are hard-coded into the tree should be cleaned up and in my opinion a new module created for them.See bug 214174 about cleaning up the icon code.
Why use different icons in Firebird? The icons in bug 99380 could work in either situation.
I think all the icons from bug 99380 would work for this one as well, except perhaps the one with the Mozilla head. (I don't know whether the Mozilla head is being used as part of Firebird's branding or not - it seems to have been removed from the application icon.)
DragonSoull: Do you mind if we change the summary to replace Mozilla head on association icons for Firebird with the Firebird logo? (Remember that eventually Firebird will have the Mozilla logo when it replaces the XPFE browser as part of the suite)
I guess that's ok :). The bug 99380 icons with the firebird icon instead of the dino head would work just as well and remove inconsistence/effort duplication.
I don't even see how to do anything but "Set as default browser" in Firebird. How do you associate images, etc? Do you have to set them manually?
For information on Image association see bug 131106.
This is partially in reply to Brian's comment: > I don't even see how to do anything but "Set as default browser" in Firebird. > How do you associate images, etc? Do you have to set them manually? I've asked around recently, and apparently the attitude with Firebird is this: make the 'set default browser' button grab some very common HTML filetypes, make it grab as minimal a set as possible, and provide NO other in-browser options to associate FB with other filetypes it can handle. It is suggested that if you want to associate FB with other filetypes, you (get this) do it *manually* through Windows Explorer. As proof of this, take a look at the fact that this bug http://bugzilla.mozilla.org/show_bug.cgi?id=216501 is WONTFIX, and at the last few comments. Brian seems to know about this. It's rather depressing. I don't think the filetypes that FB handles should be only chosen with an extension, it's so integral it should be part of default prefs. *sigh* I think this philosophy is misguided. It's not the Windows way. The Windows way is for the app to ask the user which filetypes it should handle, not the other way around. I think that this bug is moot until that philosophy is changed, as FB won't be associated with filetypes other than just basic .htm, .html :-( What people who agree with what I've just said should be doing is lobbying the main Firebird devs (BEN GOODGER) to change their stance on this issue. Firebird (in Windows) *SHOULD* have a dialog to select which filetypes to handle, above and beyond just the bare minimums, as the Mozilla suite does! Until this philosophy is adopted by the Firebird devs, there's not much point in continuing discussion with this bug as it will eventually be marked WONTFIX. :-(
I agree with firstname.lastname@example.org that Firebird should have more features to control file associations (either a file association wizard, or some buttons to grab more file types), but disagree with the implication in comment 16 that everyone who agrees should contact Ben Goodger. Lots of repetitious e-mails on the topic will more likely annoy Ben than start a constructive dialog. For this issue, and some others, there seems to be a split on whether Mozilla products are only for geeks or for the general public. For geeks the lack of a file association wizard isn't a large barrier, but to expand the audience Mozilla needs to make more things easier for more people. I've seen various feature requests or bug fixes marked as WONTFIX because they "aren't needed" (for geeks often implied), but where I believe a human factors study aimed at a wider audience would say the feature is important. The "About Mozilla" page <http://mozilla.org/about/> says "We are ... The future of the browser." Is that the future for everyone? If not it will stay fringe or become a dead end and someone else will become the future of the browser -- and that would be a waste of much of the work put into the Mozilla projects.
I think you should move this OT discussion to Mozillazine forums and I recommend pushing for a bundled extension (bug 214269), which is middle ground. I agree with you that the association methods shouldn't be left out. There has been agreement, though, that Mike Conner's patch for file associations can be moved into an extension or Firebird bundle. I do agree that some power users expect this behavior and not having it means they have to use the user-unfriendly windows explorer mode of associations. And yes, they expect this behavior, and not providing it arguably should mean we shouldn't handle the file types. Furthermore, these dialog boxes can be shared on other platforms such as Gnome or KDE which have added support for association. But that's a different bug. I'd guess the main reason for not including this feature within the builds is to not overwhelm beginning users we are trying to migrating from Internet Explorer and that's who we really need to snatch. Power users have a hard time understanding or remembering what its like for a computer novice to look at a UI like a word processor's. It overwhelms them. I think that's the main reason for this direction. I am personally willing to accept a bundled or Mozilla.org-maintained extension as a comprimse for removing it from default builds as long as it is a concession and we still provide it as an extension or bundle. > I think that this bug is moot until that philosophy is > changed Not necessarily... People who associate Mozilla [Firebird] with other file types it handles, even if they do it manually, will be assisted by icons for those filetypes within the Firebird directory. They will also be helpful for the extension, because then the icons can be changed between releases, and the extension's icons do not need to be kept up to date. It also gives a consistent look and feel for filetypes associated with Mozilla, and besides that we put a lot of work into them ;-) For these beta releases of Firebird, I don't think it really matters, but for the Mozilla 2.0 release or whatever, that is based off Firebird instead of Seamonkey, these icons will be relevant again, and they are darned spiffy. > What people who agree with what I've just said should be doing is lobbying the > main Firebird devs (BEN GOODGER) to change their stance on this issue. I believe we should try to get this as an extension and not fight an uphill battle. We should also not try to piss off other developers. That is not constructive. > discussion with this bug as it will eventually be marked WONTFIX. :-( As I said, the icons can still be provided for people doing manual associations. > For this issue, and some others, there seems to be a split on whether Mozilla > products are only for geeks or for the general public. For geeks the lack of > a file association wizard isn't a large barrier Definately. I can see a lot of geeks leaving Mozilla because they lost their ability to do things. We should at least provide bundles or extensions maintained by Mozilla.org that can be chosen during install but are not selected by default. I think that is a good compromise and Ben Goodger filed a bug on that -- bug 214269.
> I'd guess the main reason for not including this feature within the builds is to > not overwhelm beginning users we are trying to migrating from Internet Explorer > and that's who we really need to snatch. Power users have a hard time > understanding or remembering what its like for a computer novice to look at a UI > like a word processor's. I don't buy this for a second. There's no reason why FB can't do what pretty much all well-designed apps do, and stick power user features in an 'advanced' tab, that novice users know full fecking well to leave alone (and almost always do), and set some sensible defaults for them. I think the real reason is that the devs can't be bothered to code it. We don't have people like Bill Law for FB, who coded a lot of the Windows integration into the Suite. > for the Mozilla 2.0 release or whatever, that is based off Firebird instead of > Seamonkey Well if that happens, I'll be sad, for one. Right now, I prefer the Suite to Firebird owing to the FB devs' narrow, unbudging attitudes, and I can't see that changing anytime soon.
Icons are coming soon...see comment 49 in the URL. It'll be very nice when they're finished, methinks. http://www.hicksdesign.co.uk/journal/archives/000377.php
Summary: Firebird should provide icons for associated files and shortcuts → Firefox should provide icons for associated files and shortcuts
(In reply to comment #20) > Icons are coming soon...see comment 49 in the URL. It'll be very nice when > they're finished, methinks. > > http://www.hicksdesign.co.uk/journal/archives/000377.php That's just the main Firefox icon... For Windows, it really needs some document icons behind the icon, with perhaps a change of icon at very small size, to indicate that it's an associated document, and not Firefox.
(In reply to comment #21) > That's just the main Firefox icon... For Windows, it really needs some document > icons behind the icon, with perhaps a change of icon at very small size, to > indicate that it's an associated document, and not Firefox. Once again, see *comment 49* (optionally comment 48 for background info) at the referenced URL. He's *specifically* mentioning document icons. (Sorry about the bugspam to everyone else...)
Added example icon, original image created by Proneax in http://forums.mozillazine.org/viewtopic.php?t=53221 I just converted it to a Windows Icon.
Maybe it would be a good idea to put the firefox logo more to the left like Internet Explorer has it. I belive that is the standard icon layout for windows...
Isnt this the same as bug 226603? That one is reported and targeted for 1.0 by Ben.
That seems to be the case :\, should I resolve this bug has o duplicate to bug 226603?
Duping to newer bug, since that one is targeted and owned by Ben, if somebody disagrees please reopen. *** This bug has been marked as a duplicate of 226603 ***
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
This bug has way more activity, links, and comments than the other. Besides, bug 226603 is a META bug (tracking bug). Bug 226602 is the more relevant bug. I think we should let Ben decide what's a dupe of what.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 226602 ***
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.