Closed Bug 328173 Opened 19 years ago Closed 18 years ago

[meta] Overall Menu Cleanup

Categories

(Camino Graveyard :: Toolbars & Menus, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Camino1.5

People

(Reporter: samuel.sidler+old, Assigned: froodian)

References

Details

(Keywords: fixed1.8.1.1, meta)

Attachments

(1 file)

This is a tracking bug for overall menu cleanup including the addition, removal, and moving of menu items. (Note: this meta bug is not for context menu bugs.)

For now, targeting this for 1.1.
This is a representation of how *I think* all menus should look for 2.0. This includes a bunch of features which have not yet landed, most of which haven't even been patched.

Also note that some of these features may be WONTFIXed, in which case they won't belong here. :)

The changes that *can* be made, should be made soon for 1.1 and 1.2.

This is a working proposal and comments are appreciated.
> | JavaScript Console       |

JavaScript Console?  Is that going to be right below the menu item for showing a DOM tree inspector, and above the one for a view that lets you edit a page's HTML and CSS on the fly?
(In reply to comment #2)
> JavaScript Console?  Is that going to be right below the menu item for showing
> a DOM tree inspector, and above the one for a view that lets you edit a page's
> HTML and CSS on the fly?

Like I said, some features may not be implemented. I added that because Wevah mentioned that he was planning on working on it and that pink had concurred that it would be useful.
Yes, there's a good chance I will work on one, even if it has to stay in my own builds.
There are so many bugs referenced, and very many changes. Would it be possible for you to summarize the why's/rationale of the changes so we can get the discussion going?
At first glance, generally this is good, but there are a few "features" on there that really should be WONTFIXed, and some of the new labels need some tweaking.

The "Find" submenu is still a terrible idea, and the translation thing is really problematic since we'd be making the Camino UI dependant on a 3rd-party service (an optional toobar button is maybe palatable, but the menu integration is an absolute non-starter).

What about "Reload All Tabs"?

And no, "Get Info" is just "Get Info"...it doesn't require any additional user action.

I'm not sure why we need a menu item for "Discover Feeds…"; we will discover feeds automatically.
(In reply to comment #6)
> The "Find" submenu is still a terrible idea,

I'm not sure it is, once we move "Search the Web" there. Five items is overwhelming. That was part of the rational in that document. In addition, Spelling gets added and, like most apps, should be right below Find options.

> and the translation thing is
> really problematic since we'd be making the Camino UI dependant on a 3rd-party
> service (an optional toobar button is maybe palatable, but the menu integration
> is an absolute non-starter).

Yes, that's one that might never be implemented, but I included it for the sake of argument.

> What about "Reload All Tabs"?

That's an option off "Reload Page" (when holding down option or shift or whatever we choose). I forgot to list it though.

> And no, "Get Info" is just "Get Info"...it doesn't require any additional user
> action.

Okay, I wasn't sure. :)

> I'm not sure why we need a menu item for "Discover Feeds…"; we will discover
> feeds automatically.
> 

Yes, but we need a way for users without access to a mice to easily access that feature. It should also be needed if/when the status bar is hideable (just as the whitelist would live in the application menu).
Depends on: 237694
See also bug 341853 for tracking the validation of these items.
QA Contact: toolbars
Depends on: 347604
Depends on: 343299
Depends on: 331839
The en-masse 1.1 menu cleanup patch is in Bug 275170.
I don't see why Page Setup or Print should be disabled when an about: URL is up. If users want a printout of their history or bookmarks tree, we should give it to them. And since Page Setup doesn't require page content to be a valid action, it shouldn't ever be disabled (despite the fact that Safari does this, which IMO it shouldn't).

cl
Assignee: mikepinkerton → nobody
This meta has lived its purpose.  Undepping remaining open bugs and closing FIXED.
Status: NEW → RESOLVED
Closed: 18 years ago
No longer depends on: 197720, 237694, 315824, 321937, 326589, 343299
Keywords: fixed1.8.1.1
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: