Closed Bug 245765 Opened 17 years ago Closed 17 years ago
Options should be available under Edit
.... Preferences, terminology should change
GNOME HIGs require Edit->Preferences not Tools->Options... to reflect this, terminology must change throughout the app.
17 years ago
Status: NEW → ASSIGNED
br & trunk FIXED.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Verified on branch and trunk 20040607 builds.
Status: RESOLVED → VERIFIED
Does this only affect Linux? If so, could we please move Options on Windows and MacOSX also to Edit, so that Ff behaves the same on all the supported OS?
See bug 245862.
Alexander: This applies to UNIX only (GNU/Linux, Solaris, BSD etc.) Moving Options to Edit>Preferences on both Windows and Mac OS X would be wrong. These platforms have different HIGs. Apple HIGs says "$AppName>Preferences" and Windows HIG says "Tools>Options".
(In reply to comment #8) > Alexander: This applies to UNIX only (GNU/Linux, Solaris, BSD etc.) Please see bug 245862
No longer blocks: 245862
I fear you are assuming Linux (or even Unix) == Gnome. This is not the case: for instance, KDE has a great many users (actually, among my acquaintances, the vast majority of _average_ users (not techies) use KDE and not Gnome). The problem is that KDE guidelines are not the same as Gnome's. See http://developer.kde.org/documentation/standards/kde/style/basics/index.html The document clearly says that "all actions available in the Edit menu manipulate elements of the content area (nothing else!)." Actually, it recommends to have a "Settings" menu, but the "Tools" menu can hold any application-specific item. So for KDE integration, it would have been better to leave the "Options" item in the "Tools" menu. What would you think of a hidden pref enable to switch between the two guidelines ? The pref would be set one way or the other in "KDE-centric" or "Gnome-centric" packages or distributions, thus not neglecting one community in favour of the other.
(In reply to comment #10) > The problem is that KDE guidelines are not the same as Gnome's. See > http://developer.kde.org/documentation/standards/kde/style/basics/index.html Firefox is not a qt/KDE application. UNIX port is based on the GTK toolkit. So it's natural that it follows GTK/Gnome style, settings and HIG and not the qt/KDE ones. It would be pretty weird if a GTK application would use QT/KDE guidelines for the menu placement, but display GTK-based widgets. Also, this bug isn't the best place for such a religious (KDE vs Gnome) discussion. It'd be better to discuss the KDE issues e.g. in the mozillazine.org forums or Mozilla's usenet groups.
menu placement is just one of the issues here. What we really needm if KDE users want Firefox to integrate into KDE, is (in varying levels of importance) support for qt widgets and interaction with the shell (default browser info, passing external links to apps (i.e. mail)), nsITheme hookups so that we can take on the KDE theme, and appropriately #ifdeffed code so that we can use KDE button ordering, images, etc. Until there's any real effort made to resurrect the qt port, Firefox's efforts will focus on GNOME integration.
How was the decision made to support GNOME/GTK as the official toolkit for UNIX/Linux? I don't mean to add fuel to the fire. I'm just curious.
the qt port died before Mozilla 1.0 came out (i.e. stopped building/working). After nine months or so it got CVS removed since no one stepped up to maintain it. We also have a couple major corporate groups working on gtk2 (Sun and Red Hat) so that port continued to advance and be refined. Also, there are certain licensing issues with the qt toolkit that make it difficult to use that in a paid product (i.e. RH Enterprise Linux and Sun Java Desktop) without paying licensing fees.
Bug 248906 complains about the menu item being different between Windows and Linux.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.