328173 - [meta] Overall Menu Cleanup

Status: VERIFIED FIXED

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[Samuel Sidler (old account; do not CC)]

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.

Comment 1

[Samuel Sidler (old account; do not CC)]

Attachment: Overall style of menus for 2.0

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.

Comment 2

[Stuart Morgan]

> | 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?

Comment 3

[Samuel Sidler (old account; do not CC)]

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

Comment 4

[Wevah (Nate Weaver)]

Yes, there's a good chance I will work on one, even if it has to stay in my own builds.

Comment 5

[Håkan Waara]

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?

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 7

[Samuel Sidler (old account; do not CC)]

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

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

See also bug 341853 for tracking the validation of these items.

Comment 9

[froodian (Ian Leue)]

The en-masse 1.1 menu cleanup patch is in Bug 275170.

Comment 10

[Chris Lawson (gone)]

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

Comment 11

[froodian (Ian Leue)]

This meta has lived its purpose.  Undepping remaining open bugs and closing FIXED.