Every other Mozilla window has a menubar, only the Download Manager misses one. This is bad because a) You can't start other components from the Download Manager and b) it's inconsistent

I agree. I think this menu should be kinda like the JavaScript console menu bar (minimal number of items). And I also think that there should be a menu for the currently selected download containing all the elements suggested in bug 132019

adding self to cc list

Well I disagree, kind of. Right now its not possible, but I wish download manager can appear in a tab. (way too many windows alread) If we do have menu bar, that would look pretty rediclous. I wouldn't mind the menubar if an option not to display it is offered.

Mike, eh, I suppose only very few users will want to do that... every Mozilla window currently has a menubar which is not hidable, so why make an exception for download manager?

*** This bug has been marked as a duplicate of 132027 ***

VERIFIED DUPLICATE

Bug 132027 was resolved for the Mac only. Should this xp bug be re-opened?

reopening, since bug 132027 is mac-only, and this is XP. if you don't want this on all platforms, WONTFIX it, though bug 132027 comment 45 sounds like you do want that.

I'll work on this. conversation between timeless and me about which menus should be present: <timeless> i'd say file, edit, view, tools, window, help <biesi> last three with obvious content... <timeless> Edit could have delete, cut, copy, paste, perhaps reload, properties and preferences <biesi> Reload? What would that do? <timeless> although you could argue that properties would go in file or view, i don't care <timeless> re<down>load * biesi finds properties in Edit just fine <timeless> ok <timeless> view would probably do collumn choosing/sorting <timeless> file might have very few items <timeless> open would be one of them <biesi> Open? What would that do? Add a new download or open a downloaded one? <biesi> s/one/file/ * timeless notes that file>open and file>close wouldn't relate to eachother =o <timeless> the open the selected item(s) <timeless> file>new download <timeless> i think that's all i can think of <timeless> actually <timeless> forget file>close <timeless> file>hide <timeless> erm file>hide download manager <biesi> hm <biesi> if that's even possible <timeless> not your problem <timeless> however i can tell you it will be <biesi> "not my problem"? why do you think I asked? <timeless> people complain about losing their downloads when they close the last window <timeless> so there's a bug talking about making the download manager hide/minimize to tray instead of leaving 0 windows <timeless> the actual activities that the last item in the menu do aren't really significant to the person who makes the menus <timeless> your last item will do the same thing as if someone clicks the [x]

re<down>load would go in the File menu, not Edit. I would think that Properties would go in File as well, but based on the Bookmarks window it would go in Edit.

> I would think that Properties would go in File as well, but based on the > Bookmarks window it would go in Edit. The Properties dialogue for bookmarks actually allows you to edit the bookmark. This isn't the case for Download Manager files, so I think the Properties item should be in the File menu (after all, it's giving you the properties of the selected file). CC'ing mpt because his Download Manager spec had a menu bar <http://www.mozilla.org/projects/ui/navigator/downloads/#menus>.

looks like I'm going to implement mpt's spec

in explorer properties while you can't make many changes, you can make a few, in an ideal world, properties belong in the object menu which is not the edit menu. (In explorer, the object is a 'file', which is why things magically work -- in MacOSX the first menu for bookmarks could be 'Bookmark' and then you would have bookmark>properties [well, actually get info, but ...]) For now we just need to be consistent, even if we're consistently wrong.

timeless, I don't get your point. Are you suggesting renaming "File" to "Download"?

download properties require the disclosure widget. marking dependency.

1.1b is out...

implements many, but far from all parts of mpt's spec but it does implement a menubar with the most important features, which is what this bug is about. I don't want to make the patch even larger.

I have learned that UI patches are not wanted in this project. reassigning to default owner.

As I understand it, the module owner only wants a fully fledged menu bar on Mac. It would be nice if that had been mentioned when a patch was submitted, but...

biesi: You say that the patch does not implement the *whole* spec. Is it still at a point that makes it somewhat "finished"?

um, I suppose. though it still doesn't implement resume support.

*** Bug 205802 has been marked as a duplicate of this bug. ***

Comment on attachment 93924 [details] [diff] [review] patch > key = "Mac"; >+ var propsLabel = bundle.getString("propertiesLabelMac"); >+ document.getElementById("menu_properties").setAttribute("label", propsLabel); IMHO you should apply the showInShellLabel code to the properties menuitem. > case "cmd_showinshell": >+ case "cmd_copy": Putting this here makes the comment confusing. > // some apps like kazaa/morpheus let you "preview" in-progress downloads because > // that's possible for movies and music. for now, just disable indiscriminately. > return selectionCount == 1; > case "cmd_selectAll": >- return gDownloadView.view.rowCount != selectionCount; >+ return gDownloadView.view.rowCount > 0; What's with this change? > default: > return false; > } >+ return false; If this is to fix a spurious JS warning about not always returning a value then I think that's been fixed if not then please remove the default clause. >+ case "cmd_copy": >+ if (navigator.platform.indexOf("Mac") != -1) { >+ file = getFileForItem(getSelectedItem()); >+ gClipboardHelper.copyString(file.leafName); >+ } >+ else >+ gClipboardHelper.copyString(getSelectedItem().id); >+ break; Does getFileForItem not work on the Mac? >+ if (col.getAttribute("hidden") == "true") if (col.hidden) >+ var id = menuitem.getAttribute("id"); >+ id = id.substring(5, id.length); var id = menuitem.id.substr(5); will do here. >+ if (theCol.getAttribute("hidden") == "true") >+ theCol.removeAttribute("hidden"); >+ else >+ theCol.setAttribute("hidden", "true"); The hidden attribute is persisted so removing the attribute won't work. Use theCol.setAttribute("hidden", !theCol.hidden); >-<?xul-overlay href="chrome://communicator/content/tasksOverlay.xul"?> >+<?xul-overlay href="chrome://communicator/content/tasksOverlay.xul"?> ?? >+ <key id="key_stop" command="cmd_cancel" keycode="VK_ESCAPE"/> >+ <!-- the key_stop_mac key will be enabled on mac only --> >+ <key id="key_stop_mac" command="cmd_cancel" key="." modifiers="accel"/> Perhaps it would be better to use the platformDialogOverlay to pull in these key(s)? >+function download() { >+ window.opener.saveURL(urlField.value); >+} Would be nice to persist the value in a pref too. >Index: resources/locale/en-US/downloadmanager.ent .dtd, surely?

*** Bug 275569 has been marked as a duplicate of this bug. ***

Fixed in SeaMonkey 2 supposedly by bug 472001.