using apprunner on windows, the command to quit the application in the file menu reads quit - but it should say exit instead (to conform to windows UI guidelines).

Actually, it should say whatever german specifies. targetting m9

According to German's spec at http://gooey/client/5.0/specs/menu_framework/, "Sea-Monkey will be the first application to have a platform independent look and feel. To this end, there will be one set of menus for both Macintosh and Windows. Exit will become Quit." So... I'm wrong on this one. However, I find it strange that we're going with the Mac OS standard when most Navigator users (I assume) use Windows. German, would you please reconsider going with lowest-common-denominator menu wordings? Both Linux and Windows use "Exit" and not "Quit".

Bzzzt! Wrong Answer! Platform specific XUL fragments, or we will be lynched. I've already got bugs that MacOS menus need to diverge, and they ARE diverging. Or do you want an Apple menu on Windows? You can make a fully XP UI, its just that no one will like it.

I find Quit a lot more suitable as an XP standard as most newer apps, even on windows, use ctrl-Q as the keyboard shortcut. Several apps on Windows also started now using Quit as a menu item. I foresee no usability problems, so I'd really like to avoid the balkanization of the UI , if the only compelling reason for it is because it's a 'Microsoft standard'. I agree we need divergence on some isolated cases but this is not one of them. - Look what happened to borderless buttons: we had them planned for a while for 4.0 and everybody said 'but it's not a MS standard - we can't do that', as soon as IE3 and Office 97 had them, verybody felt we should do it too. - Look what happended to keyboard shortcuts for windows between 3.0 and 3.1 for Cut, Copy and Paste: MS themselves changed them to adopt the Mac standard, whereas before they had the really hard to remmeber shortcuts. Don't be surprised if MS changes things around again.

Although Microsoft may have changed keyboard shortcuts between 3.0 and 3.1, this bug specifically has to do with the File | Exit menu item. As far back as 1989, when Microsoft published the UI spec for Windows 3.0, it was Exit. My 1990 Microsoft Windows 3.0 User's Guide specifies Exit as what you select to quit a program (page 63). Exit is also what you type to exit out of a DOS window or command prompt. In short, it's the Windows standard, and it has been for nearly ten years. That's why I believe we should stick with it. As far as third-party apps using 'Quit' on Windows, well, that's a bug. That definitely does NOT conform to MS UI guidelines. Well-written Windows applications do not even have Ctrl-Q as a keyboard shortcut - the correct shortcut after all is Alt-F4 (again according to MS UI guidelines). In short, I agree with saari: it's very poor form for us to impose Mac standards on Windows users.

there's a big difference between borderless buttons and what's standard on a menu. Either quit or exit or close can refer to the app or the window. It's the standard that tells us that 'close' refers to the window and 'exit' refers to the app because on their own all 3 words mean basically the same thing. (btwI should also point out that in windows, preferences are called options and they are in the View menu)

Reassigning to german

Moving to M10 - some discussion still underway per German.

Setting on [PP] radar.

Changed mileston for later UI polishment. For now, please follow the spec.

I agree that on Windows the menu item should be called Exit.

Please stick with the specification for now, which specifies Quit across platforms. Should we encounter usability probelms, we will re-visit this issue.

No, cpratt, it's not just `third-party' apps using Ctrl+Q for Quit. It's Microsoft itself. Take a test-drive of almost any recent version of Word, Excel, PowerPoint, IE, etc. Ctrl+Q quits the app, and Ctrl+W closes the currrent window. Just like the Mac. And *no other* keyboard shortcut is shown next to the relevant menu items. (Yes, Alt+F4 works, but it's not advertised on the menu.) Quit is, as far as I can see, becoming the de facto standard -- first with the keyboard shortcut, then with the menu item.

Hm. I'll look at Office 2000 later if it's important, but this is what I find using Office 97 (SR-2) on Windows NT: Word: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q does nothing. Alt+F4 exits. Excel: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q does nothing. Alt+F4 exits. Outlook 98: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q does nothing. Alt+F4 exits. IE: File menu only says Close (remember, IE is not a separate app any longer, but part of the OS). Ctrl+Q does nothing. Alt+F4 closes the window. PowerPoint: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q exits the app. Alt+F4 does too. Based on this, I don't see Quit 'becoming the de facto standard' - it's not in any menu item, and Ctrl+Q only works in one of the apps. OTOH I don't have Office 2000 handy, so I'll have to check again with that later on. What version of Office were you using? [BTW, the reason why I care about this: I tend to use keyboard accelerators heavily. If it isn't Exit, Alt+F+X no longer works and I get very frustrated.]

OK, here's the Office 2000 story: Everything is exactly the same as Office 97 SR-2. I also tried Access, and it behaves the same as Word, Excel, and Outlook. PowerPoint is the odd man out with its (possibly undocumented) Ctrl+Q shortcut. As things stand, I don't really buy your arguments. On the other hand, this really is kind of a silly discussion. I'm tired of all of this cross-platform bickering. I'm going go with trudelle's original comment and agree that this should say whatever german wants it to stay. I'm going to mark this bug WONTFIX.

And in turn, I commit to changing/reopening this the very minute we see a usability problem with this cross-platform approach to the File menu. We'll get better data once we enter the usability testing phase. Again this is inexpensive to change but we'll go in with a cross-platform approach.

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.

adding self to cc I know this is an old bug, but if I may inject my comments...I, too, agree that the menu item needs to read Exit on win32. And I, too, don't buy the argument that it's becoming the 'de facto standard.' I verified all of Chris's observations about Office 2K (namely, that it doesn't use "Quit" anywhere, and only powerpoint uses Ctrl+Q). I also do not have a single application on my computer [and believe me, I have plenty] that uses File | Quit (*yes*, I actually checked). I have seen no proof that Quit is emerging as the standard, and I don't buy german's "look how MS has conformed to Mac in the past" argument as the reason for doing this...the look and feel of Windows is still _very_ distinct from Mac, and you simply named two examples of where Windows followed mac's example. You also said that many new windows apps are using Quit, but I'm not seeing (m)any (can you name some, please?) I disagree with the resolution of this bug as wontfix simply because the debate was getting a little repetitive or silly...that, to me, is not a valid reason to close a bug. Nor is "because that's what the spec says." I'm not going to reopen this because of german's resolution to reopen if usability testing reveals problems (although, I don't want this bug to get lost), but I think the main purpose of open source is the ability to debate certain aspects of the client, rather than closing bugs up because of excessive discussion. I know this issue has been done to death in the past, but I'm not convinced that there's a new, clearly defined standard emerging to use Quit, nor do I see a good reason to change. Were problems reported with "Exit" in nav4's usability testing? Reasons to use Exit on Windows: - The majority of win32 apps use it. - Backwards compatibility [with nav4] - No usability issues (afaik) Reasons not to use it: - To hopefully become part of some supposed trend emerging in the future If, in fact, Quit did become the standard in the coming years, we could always change it to Quit. I realize some of you would say "it's not smart to change the menu item after users are used to it," but that's exactly what we're doing now anyways with Exit->Quit. I also think it's smarter to keep Exit, since (despite what is supposedly coming in the future), that IS the standard on win32 right now...then, later, if Quit does become more popular, we can change to Quit. At least that way if Quit turns out not to become popular, we can keep Exit (otherwise, if we go with Quit now and no 'trend' emerges so we decide to switch back, we'll be really playing with the user's head -- Exit -> Quit -> Exit) I realize some of you think it's silly to debate about such a 'trivial' aspect of the UI, but I don't feel that it is. Many parts of the UI don't have a native look and feel, and it's out of our control (i.e. we're simply not going to use native widgets, and that's that). This is one thing that's easy to change and would make win32 users feel more at home with an app that already attempts to alienate them from what they're used to. I just don't see why we're abandoning it.

I agree with Blake. Surely a large proportion of Windows users instinctively close applications with Alt+F+X, if only because it is easier to get at than Alt+F4. Using `Quit' instead of `Exit' breaks this mnemonic. And I'd much rather go with standard menu text pending usability data, than go with non-standard menu text pending usability data. As Christopher Pratt noted in his thorough correction of my earlier comment, even where Windows apps use Alt+F4 to exit, it's usually not shown in the File menu -- no shortcut is shown at all. So we could easily have | | E_xit Ctrl+Q | while supporting Alt+F4 as well as Ctrl+Q. That way, if Microsoft doesn't change their standard to Quit/Ctrl+Q, we will support Alt+F+X and Alt+F4 as we should. And if Microsoft does change their standard to Quit/Ctrl+Q, we will have Ctrl+Q there ready to be used. (We needn't worry about Alt+F+Q -- nobody will use that when they can use the quicker Ctrl+Q instead.)

I'm reopening this for some concrete reasons on why we're sticking with Quit. "Silly discussion" is not a reason to close a bug WONTFIX. Valid discussion, proof of emerging trends, usability statistics, and comments/complaints from the public are. I'm afraid that we're using the idea of XP-ness as a panacea. Cross platform should not be a reason to *do* something, it should be an added benefit. Sure, it's great if we happen to work out a cross platform UI, but it's the weakest form of bond -- a bond between a user's app and a user's OS is much, much greater. I'd think that far more users would notice a contrast between the appearance of an app and the appearance of their OS than they would a difference between the app across three different platforms. Not everyone has three systems side by side to compare an app's cross-platformness, but people WILL notice when the "Exit" menu item that they use all day long in other apps isn't in ours. Yeah, it'll be a bit more work to have different items on different platforms. But I think it's worth it for an item that has the potential to be used every time the user runs the app.

I hear that one reason we're not doing this is because we don't want to write more UI. So let me get this straight. We're going to ignore the standard on the world's dominating operating system (90%+) because of a silly desire to have our app be the same on three different platforms (or just laziness?) If our strategy is to sacrifice years of UI standard and what users have gotten accustomed to, all in the name of having a UI that looks the same on three different platforms, than we really need to rethink our strategy.

sorry for spam s/more UI/more than one UI

Blake, just make a patch (which applies only to Windows) and attach it. This would hardly be `writing more than one UI', any more than having `About Mozilla' in the Apple menu (which applies only to Mac OS) is `writing more than one UI'.

I was told one of the reasons we weren't doing this is the desire to 'avoid writing more than one UI' And, as you know, I can't very well create a patch right now...although, I don't see a purpose to. The problem here isn't that no one's creating the simple patch, it's that no one's giving the "go ahead" I can't just check it in.

OK. The symptom of this bug pissed me off (an entrenched Windows user), I did a bugzilla search and found ye olde 4908. I've checked in a fix. Note that the duplicate UI claim was a sham. There've been duplicate overlay files in mac and win subfolders in xpfe/global/resources/ for quite some time now, with XUL and text for menuitems. It just so happened that the individual Mac and Windows dtd files both read "Quit" ;) My checkin changes Quit->Exit, changes the accesskey to x. I left in the command key for backward 4.x compatibility (which, strangely enough on windows uses Ctrl+Q, I guess since Alt+F4 closes the active window rather than the whole app)

I bow and humbly submit my soul to ben, god of the UI and all things Mozilla. And yes, I will bring you donuts at the developer's meeting. (thank you!)

I dont mean to be annoying but why are we fixing non nsbeta2+ trivial bugs when we've collectively agreed to first ship beta2? You start taking little trivial fixes indiscriminately and pretty soon we'll slip the goal of shipping this beta.

Vishy, were we supposed to wait another one year and three months for someone to fix this bug? In all seriousness, this was a frustrating usability problem for many of us Win32 users, and it made Mozilla look especially idiosyncratic on Win32. If you're going to take the time to make this kind of non- constructive criticism in a bug, perhaps your time would be better spent fixing those beta 2 bugs to which you refer.

is now File | Exit on 072408 mozilla win32, NT. Still File | Quit on Mac and Linux. vrfy fixed.

Like I said, I did not mean to be annoying. However we are attempting to ship beta and if everyone decides to pull in their own directions, the collective ship will not pull in the right direction. If you really feel that the nsbeta2 process is sham, you should tell jar about it. my criticism is not non-constructive. I appreciate that the bug is a polish problem and someone needs to fix it. however we've agreed to first ship nsbeta2.

This bug has been verified fixed, and I don't think everyone on the cc list needs (or wants) to hear this conversation. It sounds like a candidate for email. . .