Closed Bug 245765 Opened 17 years ago Closed 17 years ago

Options should be available under Edit.... Preferences, terminology should change


(Firefox :: Preferences, defect)

Not set





(Reporter: bugs, Assigned: bugs)


(Keywords: fixed-aviary1.0)


(3 files)

GNOME HIGs require Edit->Preferences not Tools->Options...

to reflect this, terminology must change throughout the app.
Flags: blocking1.0+
br & trunk FIXED. 
Closed: 17 years ago
Resolution: --- → FIXED
Verified on branch and trunk 20040607 builds.
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".
Blocks: 245862
(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

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

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
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.
Keywords: fixed-aviary1.0
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.