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

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

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

to reflect this, terminology must change throughout the app.

Comment 1

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch, 1

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: followup1

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: followup2

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

br & trunk FIXED. 

Comment 5

[Marek Stępień [:marcoos, inactive]]

Verified on branch and trunk 20040607 builds.

Comment 6

[Alexander Skwar]

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?

Comment 7

[Alexander Skwar]

See bug 245862.

Comment 8

[Marek Stępień [:marcoos, inactive]]

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".

Comment 9

[Alexander Skwar]

(In reply to comment #8)
> Alexander: This applies to UNIX only (GNU/Linux, Solaris, BSD etc.)

Please see bug 245862

Comment 10

[Christophe Jacquet]

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.

Comment 11

[Marek Stępień [:marcoos, inactive]]

(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. 

Comment 12

[Mike Connor [:mconnor]]

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.

Comment 13

[Dai Toyama]

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.

Comment 14

[Mike Connor [:mconnor]]

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.

Comment 15

[Jesse Ruderman]

Bug 248906 complains about the menu item being different between Windows and Linux.

Comment 16

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change