Closed Bug 63133 Opened 24 years ago Closed 23 years ago

RFE Change of Spec. Remove File>New AppDefItem. Leaving only File>New>{submenu}

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX
Future

People

(Reporter: timeless, Assigned: bugzilla)

References

()

Details

mpt and blake and others agree that having two New's is confusing. mpt and I agree that the AppDefItem is the menuitem that should be zapped. Reproducible: Always Steps to Reproduce: Get a build of mozilla. Run Mozilla [Navigator]. Click File. Actual Results: File> New Navigator Window New> Navigator Window ... ... Expected Results: File> New> Navigator Window ... ...
I don't agree. It's extremely convenient to have, for example, File | New Navigator Window, and it provides much faster and easier access than having it in a submenu (like IE). This speed gain is noticeable and worth it considering the user is often having to open new windows, e-mail messages, and composer forms, and add new bookmarks and address book cards when he/she is working in these windows.
There is no need to make `New {default item}' particularly quick to get to from the menus. If you want to make a new default item with the keyboard, Ctrl+N is quicker than using the menu. And if you want to make a new default item with the mouse, the relevant component bar item (in the case of main windows, once bug 20306 is fixed) or toolbar button (in the case of things like Bookmarks and the Address Book) is quicker than the menu. Meanwhile, not only is having two `New' items confusing, it also ruins your muscle memory for the position of the `Open' item.
I was under the impression that the task switching behavior of the component bar was intentional. I also rarely have the taskbar open (although that won't be a problem when it moves to the statusbar, but I don't really see that happening soon, if ever). I don't think we want a toolbar in the bookmarks window.
<offtopic> yes the taskbar behavior is intentional. However, mpt doesn't like it. His argument is that such behavior is for the window manager (macos doesn't have such a critter) </offtopic> I am working on a revised menu spec http://timeless.student.umd.edu/mozilla/menu_framework.html http://timeless.student.umd.edu/mozilla/menu_framework.html.diff Please comment here.
Netscape nav triage team: per Alec Flett's pre-triage recommendation, this bug is nsbeta1-.
Keywords: nsbeta1-
reassigning.
Assignee: german → blakeross
Status: NEW → ASSIGNED
Target Milestone: --- → Future
wontfix.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
v
Status: RESOLVED → VERIFIED
This bug seems to have been fixed. If we want to un-fix it, let's reopen or file a new bug on the issue. Otherwise, maybe we should reopen this and set the status over to FIXED.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.