Closed Bug 421423 Opened 16 years ago Closed 3 months ago

Use GTK+ stock items when possible

Categories

(Firefox :: Theme, defect)

x86
Linux
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: adelfino, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030610 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030610 Minefield/3.0b5pre

This is a list of places where GTK+ stock items should be used.

GTK_STOCK_ADD for Add in Languages window.
GTK_STOCK_REMOVE for Remove in Languages window.

GTK_STOCK_ADD for Add "<search engine name>" in search bar drop down.

GTK_STOCK_EDIT for Edit Keyword... in Manage Search Engine List.
GTK_STOCK_REMOVE for Remove in Manage Search Engine List.

Reproducible: Always
GTK_STOCK_GO_BACK for About Minefield in About Minefield (after clicking Credits).
Version: unspecified → Trunk
"restore defaults" should use gtk-undo
*shakes fist at reed's midair collision*

Comment #2 likely won't be addressed as it has been explained to me that just
they aren't going to change language files just cause we added an icon, and
adding an icon and leaving the < would make the button rather large.  Besides,
if we are trying to achieve the "omg teh native" feeling that I've been told we
are, then it should use GTK_STOCK_ABOUT to match the native gtk about dialogs.
Blocks: 381206
(In reply to comment #6)
> *shakes fist at reed's midair collision*
> 
> Comment #2 likely won't be addressed as it has been explained to me that just
> they aren't going to change language files just cause we added an icon, and
> adding an icon and leaving the < would make the button rather large.  Besides,
> if we are trying to achieve the "omg teh native" feeling that I've been told we
> are, then it should use GTK_STOCK_ABOUT to match the native gtk about dialogs.
> 

Seems reasonable.
(In reply to comment #5)
> "restore defaults" should use gtk-undo
> 

Just to make this easier to track, I think he refers to the menu shown by lists to select their columns.
(In reply to comment #8)
> Just to make this easier to track, I think he refers to the menu shown by lists
> to select their columns.

Yes. But the icon does not fit there. It doesn't need the icon anyway

Well, actually there is another Restore Defaults button, in Manage Search Engine List.

IMHO, using the icon in both places would be nice.
Michael said they're inappropriate.
manage search engines:

gtk-up for "move up"
gtk-down for "move down"

--

menus:

gtk-undo or trash with yellow arrow (same as in tab popup menu) for "recently closed tabs"

non-gtk new-tab for "open all in tabs"

non-gtk star icon for "bookmark this page"
Let's not try adding icons to any menu/contextmenu item we have. The previous plan was to add menu icons for

a) stock actions (=> gtk stock icons)
b) menu actions we also have toolbar buttons (new tab/window for example)

This is enough. To cite a well known person¹: "The original idea of hilighting important items in the interface is not working anymore, because everything is marked as important."

[1] http://www.tigert.com/archives/2005/09/15/ive-created-a-monster/
IMHO, icons work in a different way. They allow a vertical scan, instead of a horizontal scan, which takes more time.

If you search for something in a menu, you can focus on the "icon column" (the column formed before the actual menu items) and quickly get to the action you want/need. In some cases, this can, too, help when using a program that uses a language you don't understand; since you only look for icons.

Anyway, that's my opinion; and I think the progress Firefox has made on Linux is in no way other than awesome and brilliant. So you do deserve some hearing of your opinions ;)

--

Just for consistency, Restore Defaults (Manage Search Engine List) shouldn't use an gtk-revert-to-saved as Restore Default Set (Customiza Toolbars) will use?
ubuntu bug https://bugs.edge.launchpad.net/bugs/186771 "use more GTK stock icons" also suggests gtk-find for the search icon in quick search box.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is in direct conflict with bug 465669.
Not really... well, about the search icon: we didn't use this on purpose because we already use gtk-search for "find (text in webpage)" and it would be silly to also use it for "find (using search engine)".

The bug also suggest using another icon for RSS but the Fx3 one is also using Tango guidelines, so I don't see the problem (actually we had a very similar icon in the beginning but it was asked to NOT have a background, so it ended up being a simple glyph icon).
(In reply to comment #17)
> Not really... well, about the search icon: we didn't use this on purpose
> because we already use gtk-search for "find (text in webpage)" and it would be
> silly to also use it for "find (using search engine)".

OK. thanks for clarifying.

> 
> The bug also suggest using another icon for RSS but the Fx3 one is also using
> Tango guidelines, so I don't see the problem (actually we had a very similar
> icon in the beginning but it was asked to NOT have a background, so it ended up
> being a simple glyph icon).

I don't really understand this argument. What about users that don't use Tango-style icons?
(In reply to comment #18)
> I don't really understand this argument. What about users that don't use
> Tango-style icons?

I don't understand the problem :)

Both icons (the current as well as the proposed one) use tango style.
Depends on: 525834
What is left to close this as FIXED?
Severity: trivial → S4

The severity field for this bug is relatively low, S4. However, the bug has 3 duplicates.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.